Shared lock — ma’lumotni o‘qiyotgan transaction obyekt o‘zgarmasligini ta’minlash uchun oladigan, boshqa o‘quvchilar bilan mos, ammo yozuvchining exclusive locki bilan nomos lock turi. U ko‘pincha S lock deb belgilanadi. Bir satr yoki page ustida bir nechta shared lock bir vaqtda mavjud bo‘lishi mumkin.
Moslik qoidasi
Lock manager so‘ralgan lockni mavjud locklar bilan compatibility matrix orqali tekshiradi. Shared–shared juftligi mos: ikki transaction bir qiymatni o‘qiy oladi. Shared–exclusive juftligi mos emas: writer o‘quvchilar tugashini kutadi yoki isolation modeli boshqacha yo‘l tanlaydi.
Bu qoida o‘qish paytida boshqa transaction qiymatni almashtirib yubormasligini ta’minlaydi. Biroq shared lock qancha vaqt ushlanishi isolation level va DBMSga bog‘liq.
Isolation darajalari
Lock-based read committed rejimida shared lock statement o‘qib bo‘lgach chiqarilishi mumkin. Keyingi statement shu satrning yangi commit qilingan qiymatini ko‘rishi ehtimoli bor. Repeatable read’da o‘qilgan satr locki transaction tugaguncha saqlanib, boshqa writer’ni kutdiradi.
Serializable rejim mavjud satrlardan tashqari predicate’ga mos yangi satr qo‘shilishini ham cheklashi kerak. Buning uchun key-range yoki predicate lock ishlatilishi mumkin. Faqat mavjud rowlarga shared lock phantom anomaliyasini to‘liq to‘xtatmaydi.
MVCC tizimida oddiy SELECT shared lock olmay, transaction snapshotidagi eski row versionini o‘qishi mumkin. SELECT ... FOR SHARE yoki vendor ekvivalenti esa explicit shared/read lock so‘rab, ma’lum writerlar bilan koordinatsiya qiladi. Shuning uchun “o‘qish har doim writer’ni bloklaydi” umumiy qoida emas.
Lock granularligi
Shared lock row, key, page yoki table darajasida olinishi mumkin. Kichik granularlik parallelizmni oshiradi, lekin lock metadata sonini ko‘paytiradi. Ko‘p row lock ma’lum threshold’dan oshsa database table lockka escalation qilishi mumkin. Intent shared lock yuqori iyerarxiyada pastdagi shared locklar borligini ko‘rsatadi va table-level amallar bilan compatibility’ni tez tekshiradi.
Upgrade va deadlock
Ikki transaction avval shared lock olib, keyin ikkalasi ham exclusive lockka upgrade so‘rasa deadlock yuz berishi mumkin. Har biri boshqasining shared locki chiqishini kutadi. Agar o‘qilgan row albatta yangilanadigan bo‘lsa update lock kabi oraliq rejim ayrim DBMSlarda upgrade deadlock ehtimolini kamaytiradi.
Locklarni bir xil tartibda olish, transactionni qisqa saqlash va user inputni lock ichida kutmaslik contentionni kamaytiradi. Deadlock detector cycle topib bir transactionni rollback qilishi mumkin; application transactionni to‘liq qayta bajaradi.
Diagnostika
Blocking tahlilida blocker session, lock mode, resource va transaction boshlangan vaqt ko‘riladi. Uzoq shared lock ko‘pincha tugallanmagan transaction, sekin client yoki katta report query bilan bog‘liq. Queryni tezlashtirish lockni qisqartirishi mumkin, lekin isolation kafolatini tushunmasdan lock hint qo‘llash noto‘g‘ri natija keltiradi.
Referential integrity
Child satr qo‘shilganda database parent key mavjudligini tekshirib, parent o‘chirilmasligi uchun shared yoki key-level lock olishi mumkin. Shu sababli faqat bitta jadvalga INSERT boshqa jadvaldagi DELETE bilan bloklanadi. Foreign key ustunida mos indeks bo‘lmasa tekshiruv kengroq scan va lock ta’siriga olib kelishi mumkin.
O‘qish locki va backup
Logical export uzoq shared lock olsa writerlarni to‘xtatishi mumkin. MVCC snapshot yoki online backup mexanizmi bu ta’sirni kamaytiradi. Biroq uzoq snapshot eski versionlar va transaction logini saqlashga majbur qiladi. Backup usuli database engine’ning consistency mexanizmiga mos tanlanadi.
Bog‘liq tushunchalar
Exclusive lock, Lock compatibility, Transaction isolation, Repeatable read, Key-range lock, Intent lock, Deadlock, MVCC