Exclusive lock — transactionga ma’lum resource’ni o‘zgartirish uchun yakka kirish beradigan lock turi. Odatda X lock deb belgilanadi. U mavjud shared va boshqa exclusive locklar bilan nomos bo‘lib, bir vaqtning o‘zida zid yozuvlar bajarilishini to‘xtatadi.
Yozish jarayonidagi roli
UPDATE, DELETE yoki row yaratish amali tegishli key, row, page yoki table uchun exclusive lock olishi mumkin. Lock berilishidan oldin boshqa transactionning incompatible locklari chiqishi kutiladi. O‘zgarish bajarilgach X lock odatda transaction commit yoki rollback bo‘lguncha ushlanadi. Bu boshqa transaction commit qilinmagan qiymat ustiga yozib yuborishini va dirty readning lock-based variantini cheklaydi.
Transaction yozuvni logga kiritgani bilan lock darhol chiqmaydi. Commit visibility va durability chegarasini belgilaydi; lockdan oldin voz kechish boshqa sessionga keyin rollback qilinishi mumkin bo‘lgan holatni ko‘rsatishi mumkin.
Granularlik va intent lock
Row-level X lock yuqori concurrency beradi: boshqa transaction boshqa satrlarni o‘zgartirishi mumkin. Table-level X lock esa barcha mos kelmaydigan o‘qish va yozishni cheklaydi. Database xarajat va plan asosida granularlikni tanlaydi.
Iyerarxik lockda rowga X olishdan oldin table darajasida Intent Exclusive (IX) lock olinadi. IX table ichida pastroq resource’larda exclusive locklar borligini bildiradi. U boshqa IX bilan mos bo‘lishi mumkin, ammo table-level shared yoki exclusive so‘rov bilan compatibility qoidasi orqali to‘qnashadi.
Update lock va upgrade
O‘qib, keyin yozadigan transaction avval shared lock olsa, bir nechta transaction parallel o‘qib, keyin X ga upgrade so‘rab deadlock yaratishi mumkin. Ayrim DBMSlar update lock rejimini beradi: u shared readerlar bilan ma’lum darajada mos, ammo bir vaqtning o‘zida faqat bitta kelajak writerga ruxsat beradi.
Atomic conditional update ko‘pincha alohida “o‘qi, so‘ng yoz” ketma-ketligidan xavfsizroq:
UPDATE inventory
SET quantity = quantity - 1
WHERE product_id = 7 AND quantity > 0;
Ta’sirlangan satrlar soni shart bajarilganini ko‘rsatadi.
MVCC bilan aloqasi
MVCC readerlarga eski versionni o‘qishga imkon berib, oddiy read va X lock o‘rtasidagi blockingni kamaytiradi. Ammo ikki writer bir satrni yangilasa baribir koordinatsiya kerak. Ikkinchi writer kutishi, serialization failure olishi yoki “first updater wins” qoidasiga uchrashi mumkin.
Exclusive lock barcha biznes conflictlarni hal qilmaydi. Ikki transaction turli satrlarni yangilab umumiy invariantni buzishi mumkin; serializable isolation, constraint yoki explicit predicate locking zarur bo‘lishi mumkin.
Kutish va deadlock
Uzoq transaction X lockni uzoq ushlab, queue hosil qiladi. Tashqi HTTP so‘rovi, foydalanuvchi tasdig‘i yoki katta hisob lock ichida bajarilsa contention kuchayadi. Lock timeout kutishni cheklaydi, ammo transaction natijasini application qayta ishlashi kerak.
Deadlockda database bir ishtirokchini victim qilib rollback qiladi. Retry butun transactionni yangi snapshot bilan qayta boshlaydi. Faqat oxirgi statementni qaytarish avvalgi o‘qishlar eskirgan bo‘lsa noto‘g‘ri.
Unique key va insert
Yangi satr insert qilinganda exclusive lock faqat ko‘rinadigan rowga emas, unique indeksdagi key joyiga ham tegishi mumkin. Ikki transaction bir xil email yoki order raqamini parallel qo‘shsa bittasi kutadi, keyin birinchisi commit qilsa ikkinchisi unique violation oladi. Applicationdagi oldindan SELECT tekshiruvi bu race conditionni bartaraf etmaydi; constraint authoritative bo‘ladi.
Bog‘liq tushunchalar
Shared lock, Update lock, Intent lock, Row lock, Table lock, MVCC, Deadlock, Lock timeout