فصل 6. جلسات و معاملات

کپی رایت 2010-2022 فرد Toussi. مجوز برای توزیع این سند بدون هیچ گونه تغییر تحت شرایط مجوز HSQLDB اعطا می شود. مجوز اضافی به گروه توسعه HSQL اعطا می شود تا این سند را با یا بدون تغییر تحت شرایط مجوز HSQLDB توزیع کند.

فهرست مطالب

بررسی اجمالی

تمام اظهارات SQL در جلسات اجرا می شود. هنگامی که اتصال به پایگاه داده برقرار می شود ، جلسه ای آغاز می شود. مجوز جلسه نام کاربری است که جلسه را آغاز کرده است. یک جلسه دارای چندین ویژگی است. این خصوصیات به طور پیش فرض در ابتدا با توجه به تنظیمات پایگاه داده تنظیم می شوند.

اظهارات SQL به طور کلی بیانیه های معامله ای است. هنگامی که بیانیه معامله ای اجرا می شود ، در صورت عدم انجام معامله ، معامله را شروع می کند. اگر داده های SQL (داده های ذخیره شده در جداول) در طی یک معامله اصلاح شود ، می تواند با بیانیه بازپرداخت تغییر کند. هنگامی که یک بیانیه تعهد یا بازپرداخت اجرا می شود ، معامله به پایان می رسد. هر عبارت SQL به صورت اتمی کار می کند: بدون تغییر داده ها موفق می شود یا شکست می خورد. در صورت عدم موفقیت یک بیانیه ، خطایی مطرح می شود اما معامله به طور معمول خاتمه نمی یابد. با این حال ، برخی از شکست ها ناشی از اجرای اظهاراتی است که با اظهارات اجرا شده در سایر جلسات همزمان مغایرت دارد. چنین خرابی ها علاوه بر استثنائی که مطرح می شود منجر به بازگشت ضمنی می شود.

تعریف طرحواره و بیانیه های دستکاری نیز مطابق استاندارد SQL معامله می شوند. HypersQL تعهدات خودکار را قبل و بعد از اجرای چنین معاملات انجام می دهد. بنابراین ، اظهارات مربوط به طرحواره نمی توانند به عقب برگردند. این احتمالاً در نسخه های آینده تغییر خواهد کرد.

برخی از بیانیه ها معامله ای نیستند. بیشتر این گفته ها برای تغییر خصوصیات جلسه استفاده می شود. این گفته ها با کلمه کلیدی تنظیم شده آغاز می شود.

اگر خاصیت AutoCommit یک جلسه صحیح باشد ، هر بیانیه معامله ای توسط یک تعهد ضمنی دنبال می شود.

سطح جداسازی پیش فرض برای یک جلسه انجام شده است. این می تواند با استفاده از شیء JDBC Java. sql. Coection و روش SetTransactionIsolation آن (سطح INT) تغییر یابد. جلسه را می توان با استفاده از روش SetReadOnly (Boolean Readonly) در حالت فقط خواندنی قرار داد. هر دو روش فقط پس از تعهد یا بازگشت مجدد قابل استفاده هستند ، اما نه در طی یک معامله.

سطح جداسازی و / یا حالت ReadOnly یک معامله نیز می تواند با استفاده از بیانیه SQL اصلاح شود. شما می توانید از عبارت برای تغییر فقط حالت جداسازی ، فقط حالت فقط خواندنی یا هر دو به طور همزمان استفاده کنید. این بیانیه فقط می تواند قبل از شروع معامله یا بعد از تعهد یا بازگشت مجدد صادر شود.

این بیانیه بعداً در این فصل به تفصیل شرح داده شده است.

ویژگی ها و متغیرهای جلسه

هر جلسه دارای چندین ویژگی سیستم است. یک جلسه همچنین می تواند متغیرهای جلسه تعریف شده توسط کاربر را داشته باشد.

ویژگی های جلسه

ویژگی های سیستم منعکس کننده حالت فعلی عملکرد برای جلسه است. به این ویژگی ها با تماس های عملکردی قابل دسترسی است و می توان در نمایش داده شد. به عنوان مثال ، آنها می توانند با استفاده از مقادیر برگردانده شوند. بیانیه.

ویژگی های نامگذاری شده مانند current_user ، current_schema و غیره توابع استاندارد SQL هستند. سایر ویژگی های جلسه ، مانند حالت های خودکار یا حالت های خواندنی را می توان با استفاده از سایر توابع داخلی خوانده شد. همه این توابع در فصل ساخته شده در توابع ذکر شده است.

هر جلسه دارای یک منطقه زمانی است که منطقه زمانی JVM است که در آن اتصال ساخته شده است و می تواند با منطقه زمانی یک پایگاه داده سرور متفاوت باشد. بنابراین جلسات مختلف مشتری / سرور می توانند مناطق زمانی متفاوتی داشته باشند و اطلاعات حساس به منطقه زمانی را متفاوت نشان دهند. برای جزئیات بیشتر توضیحات بیانیه منطقه زمانی تنظیم شده را در زیر مشاهده کنید.

متغیرهای جلسه

متغیرهای جلسه متغیرهای تعریف شده توسط کاربر همان روشی هستند که متغیرهای روشها و توابع ذخیره شده ایجاد می کنند. در حال حاضر ، این متغیرها در بیانیه های عمومی SQL قابل استفاده نیستند. آنها را می توان به پارامترهای IN ، INOUT و OUT از روشهای ذخیره شده اختصاص داد. این اجازه می دهد تا روش های ذخیره شده ای که استدلال های مربوط به آن یا خارج از کشور را دارند ، برای توسعه و اشکال زدایی مفید باشد. مثال را در فصل کارهای روزمره SQL ، تحت پارامترهای رسمی مشاهده کنید.

مثال 6. 1. متغیرهای جلسه تعریف شده توسط کاربر

میزهای جلسه

با امتیازات دسترسی لازم ، جلسات می توانند به همه جدول ، از جمله جداول موقت جهانی ، که در طرحواره ها تعریف شده اند ، دسترسی پیدا کنند. اگرچه جداول موقت جهانی دارای یک نام و تعریف واحد است که در مورد همه جلسات که از آنها استفاده می کنند صدق می کند ، محتوای جداول برای هر جلسه متفاوت است. محتویات یا در پایان هر معامله یا هنگام بسته شدن جلسه پاک می شوند.

جداول جلسه متفاوت است زیرا تعریف آنها فقط در جلسه قابل مشاهده است که یک جدول را مشخص می کند. تعریف با بسته شدن جلسه کاهش می یابد. جداول جلسه متعلق به طرحواره نیست.

نحو اعلامیه براساس استاندارد SQL است. یک جدول جلسه نمی تواند محدودیت های اصلی خارجی داشته باشد ، اما می تواند محدودیت های اصلی ، منحصر به فرد یا چک داشته باشد. تعریف جدول جلسه با افزودن یا حذف ستون ها ، فهرست ها و غیره قابل تغییر نیست.

می توان با استفاده از نام آن به یک جدول جلسه اشاره کرد ، که بر یک جدول طرحواره ای با همین نام تقدم می یابد. برای تمایز یک جدول جلسه از جداول طرحواره ، می توان از نام شبه طرحواره استفاده کرد. نام جایگزین ، ماژول مستهلک می شود و در نسخه 2. 5. 1 کار نمی کند اما می تواند در نسخه 2. 6 و بعداً برای سازگاری عقب استفاده شود. یک مثال در زیر داده شده است:

مثال 6. 2. جداول جلسه موقت تعریف شده توسط کاربر

جداول جلسه را می توان در یک معامله ایجاد کرد. شاخص های اتوماتیک در صورت لزوم برای پرس و جو یا بیانیه دیگر در جداول جلسه ایجاد و استفاده می شوند. به طور پیش فرض ، داده های جدول جلسه در حافظه برگزار می شود. این را می توان با بیانیه ردیف حافظه نتیجه SET SESSION تغییر داد.

معاملات و کنترل همزمانی

HypersQL 2 برای پشتیبانی از مدلهای مختلف جداسازی معاملات کاملاً مجدداً طراحی شده است. این دیگر از مدل قدیمی 1. 8. x با "خواندن کثیف" پشتیبانی نمی کند. اگرچه افزودن اجرای مدیر معامله که از مدل میراث پشتیبانی می کند ، کاملاً امکان پذیر است ، اما فکر کردیم که این دیگر لازم نیست. سیستم جدید به شما امکان می دهد در حالی که موتور در حال کار است ، مدل جداسازی معامله را انتخاب کنید. همچنین به شما امکان می دهد سطح انزوای مختلف را برای جلسات مختلف همزمان انتخاب کنید.

HYPERSQL 2 از سه مدل کنترل همزمانی پشتیبانی می کند: قفل کردن دو فاز (2PL) ، که پیش فرض ، کنترل همزمانی چندگانه (MVCC) و یک مدل ترکیبی است که 2PL به علاوه ردیف های چندوجهی (MVLOCKS) است. در هر مدل ، از برخی از 4 سطح استاندارد جداسازی معاملات پشتیبانی می کند: خواندن غیر مجاز ، خواندن متعهد ، قابل تکرار و سریال قابل تکرار. مدل کنترل همزمانی استراتژی است که تمام جلسات را اداره می کند و بر خلاف جلسات فردی برای پایگاه داده تنظیم شده است. سطح جداسازی خاصیت هر جلسه SQL است ، بنابراین جلسات مختلف می تواند سطح انزوا متفاوت داشته باشد. در اجرای جدید ، تمام سطوح انزوا از پدیده "خواندن کثیف" جلوگیری می کنند و تغییرات غیرقابل قبول را که توسط سایر معاملات در ردیف ها انجام شده است ، نمی خوانند.

hypersql در تمام مدلهای معامله کاملاً چند رشته است. جلسات به طور همزمان به کار خود ادامه می دهند و می توانند به طور کامل از پردازنده های چند هسته ای استفاده کنند.

هر جلسه فعال یک موضوع جداگانه دارد. هنگامی که پایگاه داده به عنوان سرور اجرا می شود ، HypersQL موضوعات را اختصاص داده و مدیریت می کند. در پایگاه داده های فرآیند ، جلسات به طور غیر مستقیم از طریق اتصالات JDBC قابل دسترسی هستند. برای مدت زمان معامله باید از طریق همان موضوع در برنامه کاربر قابل دسترسی باشد. در پایگاه داده های فرآیند ، اگر برنامه کاربر موضوعی را که در حال اجرای اظهارات SQL است ، قطع کند ، در صورت گرفتار شدن توسط HypersQL قطع می شود. شما می توانید این کار را با بازپرداخت معاملات پایگاه داده تنظیم شده در مورد قطع صحیح تغییر دهید تا معامله را مجبور به وقفه کنید و وضعیت قطع شده موضوع را حفظ کنید.

مدل کنترل همزمانی یک پایگاه داده زنده قابل تغییر است. کنترل معاملات پایگاه داده تنظیم شدهمی تواند توسط یک کاربر با نقش DBA استفاده شود.

قفل دو فاز

مدل قفل دو فاز حالت پیش فرض است. به کلمه کلیدی ، قفل ها گفته می شود. در مدل 2PL ، هر جدول که توسط یک معامله خوانده می شود با یک قفل مشترک قفل شده است (قفل را بخوانید) ، و هر جدول که برای آن نوشته شده است با یک قفل اختصاصی قفل شده است (قفل نوشتن). اگر دو جلسه جداول مختلف را بخوانید و اصلاح کنید ، هر دو به طور همزمان می روند. اگر یک جلسه سعی کند یک میز را که توسط دیگری قفل شده است قفل کند ، اگر هر دو قفل به اشتراک گذاشته شوند ، پیش می رود. اگر هر یک از قفل ها یک قفل منحصر به فرد باشد ، موتور جلسه را در انتظار قرار می دهد تا جلسه دیگر معامله خود را انجام دهد یا به عقب برگرداند. اگر این عمل منجر به بن بست شود ، موتور خطایی خواهد داشت.

HypersQL همچنین از قفل صریح گروهی از جداول برای مدت زمان معامله فعلی پشتیبانی می کند. استفاده از این فرمان توسط سایر جلسات دسترسی به جداول قفل شده را مسدود می کند و تضمین می کند که جلسه فعلی می تواند خواندن مورد نظر را تکمیل کرده و روی میزهای قفل شده بنویسد.

اگر یک جدول فقط خواندنی باشد ، توسط هیچ معامله ای قفل نمی شود.

سطح انزوا غیر قابل قبول خوانده شده می تواند در حالت های 2PL برای عملیات فقط خواندنی استفاده شود. این همان خوانده شده متعهد به علاوه فقط خوانده شده است.

سطح انزوا متعهد به طور پیش فرض است. تا زمان انجام قفل قفل ها را روی جداول نگه می دارد ، اما قفل های خوانده شده را بعد از هر عمل آزاد می کند.

سطح خواندن قابل تکرار به Serializable ارتقا می یابد. این سطوح تا زمانی که مرتکب شود قفل را روی میزها نگه می دارد و می نویسد.

انجام برخی از عملیات مهم در سطح سریال امکان پذیر است ، در حالی که بقیه عملیات در سطح متعهد خوانده شده انجام می شود.

توجه: قفل دو فاز به دو دوره در زندگی یک معامله اشاره دارد. در دوره اول ، قفل ها به دست می آیند ، در دوره دوم قفل ها آزاد می شوند. پس از انتشار قفل ، هیچ قفل جدیدی به دست نمی آید.

قفل دو فاز با جداسازی عکس فوری

این مدل به عنوان MVLOCKS گفته می شود. تا آنجا که به روزرسانی ها مربوط می شود ، به همان روش معمولی 2PL کار می کند.

Isolation Snapshot یک استراتژی همزمانی چندگانه است که از عکس فوری کل بانک اطلاعاتی در زمان شروع معامله استفاده می کند. در این مدل ، معاملات فقط خواندنی از جداسازی عکس فوری استفاده می کنند. در حالی که سایر جلسات مشغول تغییر پایگاه داده هستند ، جلسه فقط خواندنی یک نمای مداوم از پایگاه داده را مشاهده می کند و حتی در صورت قفل شدن در جلسات دیگر برای به روزرسانی ، می تواند به همه جداول دسترسی پیدا کند.

برنامه های زیادی برای این شیوه کار وجود دارد. در مجموعه داده های به روز شده ، این حالت امکان دسترسی بدون وقفه به داده ها را فراهم می کند.

مشاجره قفل در 2PL

هنگامی که چندین اتصالات برای دسترسی به پایگاه داده استفاده می شود ، مدیر معامله فعالیت های آنها را کنترل می کند. هنگامی که هر معامله فقط در یک جدول واحد می خواند یا می نویسد ، هیچ مشاجره ای وجود ندارد. هر معامله منتظر می ماند تا بتواند قفل را بدست آورد و سپس عملیات را انجام دهد و مرتکب شود. اعتراضات هنگامی اتفاق می افتد که معاملات در بیش از یک جدول خوانده شده و می نویسند ، یا خواندن را انجام می دهند ، و به دنبال آن نوشتن ، در همان جدول انجام می شود.

به عنوان مثال ، هنگامی که جلسات در سطح سریال کار می کنند ، هنگامی که چندین جلسه ابتدا از یک جدول خوانده می شود تا بررسی کند که آیا یک ردیف وجود دارد ، در صورت وجود یک ردیف در همان جدول قرار دهید ، مشاجره منظم وجود خواهد داشت. معامله A از جدول خوانده می شود ، سپس معامله B را انجام می دهد. اکنون اگر معامله A یا B سعی در وارد کردن یک ردیف داشته باشد ، باید خاتمه یابد زیرا معامله دیگر قفل مشترکی را در جدول دارد. اگر به جای دو عمل ، از یک عبارت ادغام واحد برای انجام خواندن و نوشتن استفاده شود ، هیچ مشاجره ای رخ نمی دهد زیرا هر دو قفل به طور همزمان بدست می آیند.

از طرف دیگر ، گزینه بدست آوردن قفل های لازم با یک عبارت جدول قفل صریح وجود دارد. این بیانیه باید قبل از اظهارات دیگر اجرا شود و باید نام همه جداول و قفل های مورد نیاز را در بر بگیرد. پس از این بیانیه ، تمام اظهارات دیگر در معامله قابل اجرا و معامله انجام می شود. تعهد تمام قفل ها را حذف می کند.

HypersQL قبل از تلاش برای اجرای بیانیه ، بن بست را تشخیص می دهد. هنگامی که قفل پس از اتمام بیانیه آزاد شد ، اولین معامله ای که منتظر قفل است مجاز به ادامه کار است.

hypersql کاملاً چند رشته است. بنابراین به معاملات مختلف اجازه می دهد تا زمانی که منتظر قفل کردن همان جدول برای نوشتن نیستند ، به طور همزمان اجرا کنند.

قفل در روال SQL و محرک

در هر دو مدل قفل و MVLOCKS ، روالهای SQL (توابع و رویه ها) و محرک ها در ابتدای اجرای معمول ، تمام قفل های خواندن و نوشتن را بدست می آورند. اظهارات SQL موجود در روال یا ماشه همه بدون بن بست اجرا می شوند زیرا تمام قفل ها قبلاً به دست آمده اند. در پایان اجرای روال یا ماشه ، اگر سطح جداسازی جلسه انجام شود ، قفل های خواندن آزاد می شوند.

در مدل MVCC ، هیچ قفل مشترک و خواندن وجود ندارد. از قفل های منحصر به فرد در ردیف های جداگانه استفاده می شود ، اما استفاده از آنها متفاوت است. معاملات می توانند به طور هم زمان ، بدون انتظار برای معاملات دیگر ، همان جدول را همزمان بخوانند و اصلاح کنند. سطح جداسازی استاندارد SQL توسط کاربرد کاربر استفاده می شود ، اما این سطح جداسازی به سطح جداسازی MVCC ترجمه می شود که قوام یا جداسازی عکس فوری را می خوانند.

هنگامی که معاملات در سطح متعهد خوانده شده انجام می شود ، هیچ درگیری به طور معمول رخ نخواهد داد. اگر معامله ای که در این سطح انجام می شود ، می خواهد ردیفی را تغییر دهد که توسط یک معامله غیرقابل قبول دیگر اصلاح شده باشد ، موتور معامله را در انتظار قرار می دهد ، تا اینکه معامله دیگر مرتکب شده باشد. سپس معامله به طور خودکار ادامه می یابد. این سطح جداسازی خوانده شده است.

موتور کاملاً از بن بست جلوگیری می کند. تنظیم پایگاه داده، SET DATABASE TRANSACTION ROLLBACK ON CONFLICT، تعیین می کند که در صورت بن بست چه اتفاقی می افتد. در تئوری، تعارض (بن بست) در صورتی امکان پذیر است که هر تراکنش منتظر ردیف متفاوتی باشد که توسط تراکنش دیگر اصلاح شده است. در این حالت، یکی از تراکنش ها بلافاصله با برگرداندن تمام اظهارات قبلی در تراکنش خاتمه می یابد تا تراکنش دیگر ادامه یابد. اگر تنظیمات با علامت به FALSE تغییر کرده باشد، جلسه ای که از اجرای دستور ایجاد بن بست اجتناب کرده است، یک خطا برمی گرداند، اما بدون برگرداندن عبارات قبلی در تراکنش فعلی. این جلسه باید یک دستور جایگزین برای ادامه و انجام یا عقب انداختن تراکنش انجام دهد. هنگامی که جلسه متعهد شد یا برگشت، جلسه دیگر می تواند ادامه یابد. این اجازه می دهد تا حداکثر انعطاف پذیری و سازگاری با موتورهای پایگاه داده دیگر که تراکنش را پس از بن بست عقب نشینی نمی کنند.

هنگامی که تراکنش ها در سطوح جداسازی REPEATABLE READ یا SERIALIIZABLE اجرا می شوند، احتمال بروز تضاد بیشتر است. هیچ تفاوتی در عملکرد بین این دو سطح ایزوله وجود ندارد. این سطح ایزوله ایزوله SNAPSHOT نامیده می شود.

در این حالت، زمانی که مدت دو تراکنش با هم تداخل داشته باشد، اگر یکی از تراکنش ها یک ردیف را اصلاح کرده باشد و تراکنش دوم بخواهد همان ردیف را اصلاح کند، عمل تراکنش دوم با شکست مواجه می شود. این اتفاق می افتد حتی اگر اولین تراکنش قبلاً انجام شده باشد. موتور تراکنش دوم را باطل می کند و تمام تغییرات آن را برمی گرداند. اگر تنظیم با علامت نادرست تغییر کند، تراکنش دوم فقط یک خطا را بدون بازگشت به عقب برمی گرداند. برنامه باید یک عبارت جایگزین برای ادامه یا بازگرداندن تراکنش انجام دهد.

در مدل MVCC، READ UNCOMMITTED به READ COMMITTED ارتقا می یابد، زیرا معماری جدید بر اساس ردیف های چند نسخه ای برای داده های غیرمتعهد است و ممکن است بیش از یک نسخه برای برخی از ردیف ها وجود داشته باشد.

با MVCC، زمانی که یک تراکنش فقط داده ها را می خواند، بدون در نظر گرفتن اینکه سایر تراکنش ها ممکن است انجام دهند، انجام می شود و تکمیل می شود. این به تنها خواندنی بودن تراکنش یا حالت های جداسازی بستگی ندارد.

انتخاب مدل معامله

استاندارد SQL سطح انزوا را به عنوان حالت های عملکردی تعریف می کند که از سه پدیده ناخواسته ، "خواندن کثیف" ، "خواندن فازی" و "فانتوم ردیف" در طی یک معامله جلوگیری می کند. پدیده "خواندن کثیف" زمانی اتفاق می افتد که یک جلسه می تواند تغییراتی را در یک ردیف ایجاد شده توسط یک جلسه غیرقابل قبول دیگر بخواند. پدیده "خواندن فازی" هنگامی اتفاق می افتد که یک جلسه یک ردیف را می خواند و ردیف توسط جلسه دیگری که مرتکب می شود اصلاح می شود ، سپس جلسه اول دوباره ردیف را می خواند. پدیده "Phantom Row" هنگامی اتفاق می افتد که یک جلسه عملیاتی را انجام می دهد که چندین ردیف را تحت تأثیر قرار می دهد ، به عنوان مثال ، ردیف ها را شمارش می کند یا آنها را با استفاده از یک شرایط جستجو تغییر می دهد ، سپس یک جلسه دیگر یک یا چند ردیف اضافه می کند که همان وضعیت جستجو را انجام می دهند و مرتکب می شوند ، سپسجلسه اول عملیاتی را انجام می دهد که به نتایج آخرین عملیات خود متکی است. با توجه به استاندارد ، سطح انزوا قابل استفاده از هر سه پدیده جلوگیری می کند و همچنین تضمین می کند که تمام تغییرات انجام شده در طی یک معامله می تواند به عنوان یک سری از تغییرات بی وقفه در پایگاه داده در نظر گرفته شود بدون اینکه هیچگونه معامله دیگری به هیچ وجه پایگاه داده را برای مدت زمان اینها تغییر دهد. اقدامات. تغییرات انجام شده توسط سایر معاملات قبل از شروع معامله سریال یا پس از پایان ، در نظر گرفته می شود. سطح متعهد خواندن فقط از "خواندن کثیف" جلوگیری می کند ، در حالی که سطح خواندن قابل تکرار از "خواندن کثیف" و "خواندن فازی" جلوگیری می کند ، اما نه "ردیف فانتوم".

استاندارد به موتور اجازه می دهد تا سطح جداسازی بالاتری را نسبت به درخواست درخواست بازگرداند. HypersQL یک درخواست غیرقانونی خوانده شده برای خواندن متعهد را ترویج می کند و یک درخواست خواندن قابل تکرار را به Serializable ترویج می کند.

مدل MVCC به طور مستقیم توسط استاندارد پوشانده نمی شود. تحقیقات ثابت کرده است که سطح قوام خوانده شده الزامات (و قوی تر از) سطح متعهد خوانده شده است. سطح جداسازی عکس فوری از سطح قوام خوانده شده قوی تر است. از سه ناهنجاری تعریف شده توسط استاندارد جلوگیری می کند و بنابراین قوی تر از سطح خواندن قابل تکرار است که طبق استاندارد تعریف شده است. هنگام کار با مدل MVCC ، HYPERSQL با یک تنظیم قابل تکرار یا سریال قابل تکرار برای معامله به عنوان جداسازی عکس فوری رفتار می کند.

همه حالت ها را می توان با هر تعداد اتصال همزمان مورد نیاز استفاده کرد. مدل پیش فرض 2PL برای برنامه هایی با یک اتصال واحد یا برنامه هایی که به شدت به جداول مشابه برای نوشتن دسترسی ندارند، مناسب است. با چندین اتصال همزمان، MVCC را می توان برای اکثر برنامه ها استفاده کرد. هر دو سطح READ CONSISTENCY و SNAPSHOT IOLATION قوی تر از سطح مربوط به READ COMMITTED در حالت 2PL هستند. برخی از برنامه ها حداقل برای برخی از عملیات های خود به تراکنش های SERIALIZABLE نیاز دارند. برای این کاربردها می توان از یکی از حالت های 2PL استفاده کرد. تغییر مدل همزمانی در زمانی که پایگاه داده عملیاتی است امکان پذیر است. بنابراین، مدل را می توان برای مدت زمان برخی از عملیات های خاص، مانند همگام سازی با منبع داده دیگر یا انجام تغییرات انبوه در محتویات جدول، تغییر داد.

همه مدل های همزمان بسیار سریع عمل می کنند. هنگامی که عملیات تغییر داده ها عمدتاً روی یک جداول باشد، مدل MVCC ممکن است سریعتر باشد، به خصوص با پردازنده های چند هسته ای.

تغییر طرحواره و پایگاه داده

چند دستور SQL وجود دارد که باید در طول اجرای خود به وضعیت ثابت پایگاه داده دسترسی داشته باشند. این عبارات که شامل CHECKPOINT و BACKUP می شوند، هنگام شروع به کار روی تمام جداول پایگاه داده قفل انحصاری می گذارند.

برخی از دستورات دستکاری طرحواره یک قفل انحصاری را روی یک یا چند جدول قرار می دهند. به عنوان مثال، تغییر ستون های یک جدول، جدول را منحصرا قفل می کند.

در مدل MVCC، تمام عباراتی که نیاز به قفل انحصاری در یک یا چند جدول دارند، یک قفل انحصاری بر روی کاتالوگ پایگاه داده قرار می دهند تا زمانی که کامل شوند.

اثر این قفل های انحصاری شبیه به اجرای دستورات دستکاری داده ها با قفل های نوشتن است. جلسه ای که قرار است دستور تغییر طرحواره را اجرا کند تا زمانی که هیچ جلسه دیگری روی هیچ یک از اشیاء قفل نکند منتظر می ماند. در این مرحله عملیات خود را شروع می کند و اشیاء را قفل می کند تا از دسترسی هر جلسه دیگری به اشیاء قفل شده جلوگیری کند. به محض اتمام عملیات، تمام قفل ها برداشته می شوند.

دسترسی همزمان به جداول

ذکر شد که هیچ محدودیتی در تعداد جلسات وجود ندارد که بتوانند به جداول دسترسی پیدا کنند و همه جلسات به طور همزمان در اجرای چند رشته کار می کنند. با این حال ، منابع داخلی وجود دارد که به اشتراک گذاشته می شوند. دسترسی همزمان به این منابع می تواند کارایی کلی سیستم را کاهش دهد. جداول حافظه و متن منابع را به اشتراک نمی گذارد و دسترسی چند رشته ای را مسدود نمی کند. با استفاده از جداول ذخیره شده ، هر ردیف تغییر عملکرد فایل و حافظه نهان آن را لحظه به لحظه مسدود می کند. این کار به طور جداگانه برای هر ردیف انجام می شود ، بنابراین بیانیه چند ردیف ، به روزرسانی یا حذف بیانیه به جلسات دیگر اجازه می دهد تا در حین اجرای آن به پرونده دسترسی پیدا کنند. با استفاده از جداول ذخیره شده ، عملیات انتخابی یکدیگر را مسدود نمی کند ، اما انتخاب از جداول مختلف و قسمت های مختلف یک جدول بزرگ باعث می شود که حافظه نهان به طور مکرر به روز شود و عملکرد کلی را کاهش دهد.

الگوی دسترسی جدید برعکس الگوی دسترسی نسخه 1. 8. x است. در نسخه قدیمی ، حتی وقتی 20 جلسه به طور فعال در حال خواندن و نوشتن هستند ، فقط یک جلسه واحد در یک زمان یک جمله SQL را به طور کامل انجام می دهد ، قبل از دسترسی به جلسه بعدی. در نسخه جدید ، در حالی که یک جلسه در حال انجام یک عبارت منتخب و خواندن ردیف های یک جدول ذخیره شده برای ساختن یک مجموعه نتیجه است ، یک جلسه دیگر ممکن است یک عبارت به روزرسانی را انجام دهد که ردیف های همان جدول را می خواند و می نویسد. این دو عمل بدون هیچ گونه درگیری انجام می شود ، اما حافظه پنهان ردیف بیشتر از زمانی که یک عمل پس از اتمام عمل دیگر انجام می شود ، بیشتر به روز می شود.

جلسات مشاهده

از آنجا که hypersql چند رشته ای است ، می توانید جلسات فعلی و وضعیت آنها را از هر جلسه سرپرست مشاهده کنید. جدول information_schema. system_sessions شامل لیست جلسات باز ، شناسه های منحصر به فرد آنها و بیانیه ای است که در حال حاضر اجرا شده یا انتظار اجرای هر جلسه است. برای هر جلسه ، لیست جلساتی را که منتظر تعهد آن هستند ، یا جلسه ای که این جلسه در انتظار آن است ، نشان می دهد.

بیانیه های جلسه و کنترل معاملات

جلسه

بیانیه جلسه را تغییر دهید

توسط یک مدیر برای بستن جلسه دیگر یا بازگرداندن معامله در یک جلسه دیگر استفاده می شود. این بیانیه با سایر اظهارات مورد بحث در این فصل متفاوت است زیرا برای تغییر تنظیمات جلسه فعلی استفاده نمی شود. هنگامی که از بیانیه پایان استفاده می شود ، عبارت فعلی که منتظر اجرا است یا اجرا می شود سقط می شود. هنگامی که از انتشار استفاده می شود ، معامله فعلی با بازگشت به عقب خاتمه می یابد. جلسه باز است. نزدیک ممکن است پس از اتمام انتشار استفاده شود.

شناسه جلسه به عنوان A در این جمله استفاده می شود. سرپرست می تواند از جدول information_schema. system_sessions برای یافتن شناسه جلسه جلسات دیگر استفاده کند.

از این موارد برای پاک کردن و تنظیم مجدد حالتهای مختلف جلسه فعلی استفاده می شود. هنگامی که همه مشخص شده است ، معامله فعلی به عقب برگردانده می شود ، تنظیمات جلسه مانند منطقه زمانی ، طرح فعلی و غیره در زمان باز شدن جلسه به حالت اصلی خود بازگردانده می شوند و تمام مجموعه های نتیجه باز بسته می شوند و جداول موقت پاک می شوند. هنگامی که مجموعه نتیجه مشخص شده است ، تمام مجموعه های نتیجه باز در حال حاضر بسته شده و منابع منتشر می شوند. هنگامی که داده های جدول مشخص شده است ، داده ها در کلیه جداول موقت پاک می شوند.

تنظیم خودکار

دستور AutoCommit را تنظیم کنید

هنگامی که یک جلسه SQL با ایجاد اتصال JDBC آغاز می شود ، در حالت AutomMit است. در این حالت ، پس از هر بیانیه SQL ، یک تعهد به طور خودکار انجام می شود. این عبارت حالت را تغییر می دهد. این معادل استفاده از روش SetAutoCommit (Boolean AutoCommit) شیء اتصال JDBC است.

معامله را شروع کنید

بیانیه معامله را شروع کنید

معامله SQL را شروع کرده و ویژگی های آن را تنظیم کنید. کلیه بیانیه های SQL معامله ای به طور خودکار معامله را شروع می کنند ، بنابراین استفاده از این بیانیه ضروری نیست. اگر بیانیه در وسط معامله خوانده شود ، یک استثناء پرتاب می شود.

معامله

مشخصات معاملات بعدی را تنظیم کنید

ویژگی های معامله بعدی را در جلسه فعلی تنظیم کنید. این بیانیه فقط در معاملات بعدی تأثیر دارد و هیچ تاثیری در معاملات آینده پس از بعدی ندارد.

خصوصیات معامله

:: = بخوانید غیرقانونی |بخوانید متعهد |قابل تکرار خواندن |سریال پذیر

مشخصات معاملات را مشخص کنید.

مثال 6. 3. تنظیم ویژگی های معامله

محدودیت ها را تنظیم کنید

بیانیه حالت محدودیت ها را تنظیم کنید

اگر بیانیه در حین معامله صادر شده باشد، در مورد بقیه تراکنش جاری اعمال می شود. اگر بیانیه زمانی صادر شود که تراکنش فعال نباشد، فقط برای تراکنش بعدی در جلسه جاری اعمال می شود. HyperSQL هنوز از این ویژگی پشتیبانی نمی کند.

میز قفل

بیانیه جدول قفل

در برخی شرایط، که چندین تراکنش همزمان در حال انجام است، ممکن است لازم باشد که تراکنش متشکل از چندین بیانیه تکمیل شود، بدون اینکه به دلیل بن بست احتمالی خاتمه یابد. هنگامی که این دستور اجرا می شود، صبر می کند تا بتواند تمام قفل های لیست شده را به دست آورد، سپس برمی گردد. اگر به دست آوردن قفل ها منجر به بن بست شود، خطا مطرح می شود. عبارات SQL به دنبال این عبارت از قفل هایی استفاده می کنند که قبلاً به دست آمده اند (و در صورت لزوم قفل های جدید دریافت می کنند) و می توانند بدون انتظار ادامه دهند. همه قفل ها با صدور بیانیه COMMIT یا ROLLBACK آزاد می شوند.

هنگامی که سطح جداسازی یک جلسه READ COMMITTED باشد، قفل های خواندن بلافاصله پس از اجرای دستور آزاد می شوند، بنابراین در این حالت فقط باید از قفل های WRITE استفاده کنید. از طرف دیگر، می توانید قبل از قفل کردن جداول برای تراکنش خاصی که باید به طور مداوم و بدون بن بست تمام شود، به حالت جداسازی SERIALIZABLE بروید. بهتر است این عبارت را در ابتدای معامله با لیست کامل قفل های خواندن و نوشتن مورد نیاز اجرا کنید.

در حال حاضر، زمانی که مدل کنترل تراکنش پایگاه داده MVCC باشد، این دستور هیچ تاثیری ندارد.

مثال 6. 4. جداول قفل

SAVEPOINT

یک ذخیره سازی ایجاد کنید. این دستور در طول تراکنش SQL استفاده می شود. این یک نقطه عطف برای معامله فعلی ایجاد می کند. SAVEPOINT می تواند در مرحله بعدی تراکنش برای بازگرداندن تراکنش به نقطه عطف استفاده شود.

RELEASE SAVEPOINT

انتشار بیانیه savepoint

یک نقطه ذخیره را از بین ببرید. این دستور به ندرت استفاده می شود زیرا بسیار مفید نیست. یک SAVEPOINT را که قبلاً تعریف شده است حذف می کند.

مرتکب شدن

::= COMIT [ کار ] [ و [ نه ] زنجیره ]

تراکنش فعلی SQL را با commit خاتمه دهید. این باعث می شود تمام تغییرات در پایگاه داده دائمی شود.

بازگشت به عقب

::= بازگشت [ کار ] [ و [ نه ] زنجیر ]

تراکنش فعلی SQL را برگردانید و آن را خاتمه دهید. بیانیه تمام اقدامات انجام شده در طول تراکنش را به عقب برمی گرداند. اگر NO CHAIN مشخص شده باشد، یک تراکنش SQL جدید درست پس از بازگشت شروع می شود. معامله جدید خواص معامله قدیمی را به ارث می برد.

بازگشت به ذخیره

:: = بازگشت [کار] برای SavePoint

بخشی از معامله SQL فعلی و ادامه معامله. این بیانیه تمام اقدامات انجام شده پس از ایجاد SavePoint مشخص شده را بازگرداند. همین اثر را می توان با روش Rollback (SavePoint SavePoint) از شیء اتصال JDBC بدست آورد.

مثال 6. 5. بازپرداخت

قطع شدن

جلسه SQL فعلی را خاتمه دهید. بستن اتصال JDBC همان اثر این دستور را دارد.

مشخصات جلسه را تنظیم کنید

بیانیه مشخصات جلسه را تنظیم کنید

یک یا چند ویژگی را برای جلسه فعلی SQL تنظیم کنید. این دستور برای تنظیم حالت معامله برای جلسه استفاده می شود. این برای همه معاملات تا زمان بسته شدن جلسه یا استفاده بعدی از این دستور تحمل می شود. با عملکرد IsReadonly () می توان به حالت فقط خواندنی دسترسی پیدا کرد.

مثال 6. 6. تنظیم ویژگی های جلسه

مجوز جلسه را تنظیم کنید

جلسه شناسه کاربر جلسه را تنظیم کنید

شناسه کاربر SQL-Session را تنظیم کنید. این عبارت کاربر فعلی را تغییر می دهد. کاربر که این دستور را اجرا می کند باید نقش تغییر_authorization یا نقش DBA را داشته باشد. پس از اجرای این بیانیه ، تمام اظهارات SQL با امتیازات کاربر جدید اجرا می شود. مجوز فعلی را می توان با توابع فعلی_USER و Session_User دسترسی پیدا کرد.

مثال 6. 7. تنظیم مجوز جلسه

نقش تعیین شده

بیان نقش

نام نقش SQL-Session و نام نقش فعلی را برای زمینه فعلی SQL تنظیم کنید. کاربر که این دستور را اجرا می کند باید نقش مشخصی داشته باشد. اگر هیچ کدام مشخص نشده باشد ، سپس جریان قبلی_رول از بین می رود. تأثیر این امر برای طول عمر جلسه ادامه دارد. با عملکرد فعلی_رول می توان به نقش فعلی دسترسی پیدا کرد.

تنظیم منطقه زمانی

بیانیه منطقه زمانی محلی را تنظیم کنید

جابجایی منطقه زمانی پیش فرض فعلی را برای جلسه فعلی SQL تنظیم کنید. با شروع جلسه ، جابجایی منطقه زمانی به منطقه زمانی مشتری تنظیم می شود. این دستور جابجایی منطقه زمانی را تغییر می دهد. تأثیر این امر برای طول عمر جلسه ادامه دارد. در صورت مشخص شدن محلی ، جابجایی منطقه زمانی به منطقه زمانی محلی جلسه که قبل از استفاده از دستور در حال اجرا بود ، برمی گردد.

از نسخه 2. 7 ، رشته های منطقه ای که نشانگر مناطق جغرافیایی است می توان استفاده کرد. این منطقه اغلب از زمان صرفه جویی در نور روز پشتیبانی می کنند.

این دستور با پایگاه داده های فرآیند خوب کار می کند. هنگامی که جلسات برای اتصال به سرور است ، از این دستور به طور کلی نباید استفاده شود زیرا فقط بر قسمت سرور جلسه تأثیر می گذارد. با اتصالات مشتری / سرور ، تنها راه مشخص کردن منطقه زمانی جلسه که با منطقه زمانی محلی متفاوت است ، تنظیم منطقه زمانی JVM مشتری قبل از اتصال به پایگاه داده است.

مثال 6. 8. تنظیم منطقه زمانی جلسه

کاتالوگ تنظیم شده

بیانیه کاتالوگ را تنظیم کنید

نام طرحواره پیش فرض را برای نامهای غیر صلاحیت استفاده شده در بیانیه های SQL که مستقیماً در جلسات فعلی تهیه یا اجرا می شوند ، تنظیم کنید. از آنجا که فقط یک کاتالوگ در پایگاه داده وجود دارد ، فقط از نام این کاتالوگ استفاده می شود. به کاتالوگ فعلی با عملکرد فعلی_Catalog قابل دسترسی است.

طرح

بیانیه طرحواره

نام طرحواره پیش فرض را برای نامهای غیر صلاحیت استفاده شده در بیانیه های SQL که مستقیماً در جلسات فعلی تهیه یا اجرا می شوند ، تنظیم کنید. تأثیر این امر برای طول عمر جلسه ادامه دارد. فرم استاندارد SQL به نام طرحواره به عنوان یک رشته تک لایه نیاز دارد. HypersQL همچنین امکان استفاده از شناسه برای طرحواره را فراهم می کند. با عملکرد فعلی_Schema می توان به طرح فعلی دسترسی پیدا کرد.

مسیر تعیین شده

بیانیه مسیر را تنظیم کنید

مسیر SQL را که برای تعیین موضوع روال دعوت های روتین با نام های معمول غیرمجاز استفاده شده در بیانیه های SQL که مستقیماً در جلسات فعلی تهیه یا اجرا می شوند ، تنظیم کنید. تأثیر این امر برای طول عمر جلسه ادامه دارد.

Maxrows را تنظیم کنید

بیانیه Rows Max را تنظیم کنید

عملکرد عادی جلسه هیچ محدودیتی در تعداد ردیف های برگشتی از یک عبارت SELECT ندارد. این دستور حداکثر تعداد ردیف های نتیجه برگشتی را با اجرای نمایش داده شد.

این بیانیه تأثیر مشابهی با روش SetMaxrows (Int Max) رابط بیانیه JDBC دارد ، اما بر نتایج برگشتی فقط از اجرای بیانیه بعدی تأثیر می گذارد. پس از اجرای بیانیه بعدی ، حد حداکثر حذف می شود.

فقط با این دستور می توان از مقادیر صفر یا مثبت استفاده کرد. مقدار بیش از هر مقدار مشخص شده با روش setMaxrows (int max) یک عبارت jdbc را تحت الشعاع قرار می دهد. بیانیه SET MAXROWS 0 به معنای محدودیتی نیست.

می توان تعداد ردیف های برگشتی را از جمله های منتخب فقط با ردیف های Fetch یا گزینه جایگزین آن محدود کرد. بنابراین ، این دستور برای استفاده عمومی توصیه نمی شود. تنها استفاده قانونی از این دستور برای بررسی و آزمایش نمایش داده شدگان است که ممکن است تعداد بسیار زیادی از ردیف ها را برگرداند.

تنظیم ردیف های حافظه نتیجه جلسه

تنظیم خط ردیف حافظه نتیجه جلسه را تنظیم کنید

به طور پیش فرض ، جلسه از حافظه برای ساخت مجموعه های نتیجه ، نتایج زیرشاخه و جداول موقت استفاده می کند. این دستور حداکثر تعداد ردیف های نتیجه (و جداول موقت) را که باید در حافظه نگه داشته شود ، تعیین می کند. اگر تعداد ردیف نتیجه یا جدول موقت از تنظیمات فراتر رود ، نتیجه روی دیسک ذخیره می شود. پیش فرض 0 است ، به این معنی که همه مجموعه های نتیجه در حافظه برگزار می شوند.

این بیانیه فقط در مورد جلسه فعلی اعمال می شود. تنظیم پایگاه داده عمومی:

ردیف های حافظه نتیجه پیش فرض پایگاه داده را تنظیم کنید

نادیده گرفتن

بیانیه پرونده را نادیده بگیرید

این یک روش میراث برای ایجاد ستون های حساس به موارد است. هنوز پشتیبانی می شود اما برای استفاده توصیه نمی شود.

نوع مورد استفاده برای ستون های جدید جدول Varchar را تنظیم می کند. به طور پیش فرض ، ستون های کاراکتر در پایگاه داده های جدید حساس به مورد هستند. اگر از تنظیم IgnorEcase درست استفاده شود ، تمام ستون های Varchar در جداول جدید تنظیم شده اند تا از یک جمع استفاده کنند که رشته ها را برای مقایسه به حروف بزرگ تبدیل می کند. در جدیدترین نسخه های HypersQL می توانید مجموعه های پایگاه داده و برای هر ستون را مشخص کنید و حتی در همان جدول ، برخی از ستون ها حساس به مورد و برخی از آنها نیست. از استحکام جمع آوری برای مجبور کردن مقایسه حساس به موارد استفاده می شود. مجموعه ها در فصل Schemas و Database Objects بحث شده است.

این جمله باید قبل از ایجاد جداول تغییر یابد. جداول موجود و داده های آنها تحت تأثیر قرار نمی گیرد.