Business lock — texnik satr yoki mutexni emas, biznes obyekt ustida bir-biriga zid operatsiyalarni muvofiqlashtiradigan mantiqiy qulfdir. Masalan, buyurtmani bir vaqtda ikki operator tasdiqlamasligi yoki mavjud o‘rindiq ikki mijozga sotilmasligi kerak. Qulfning identifikatori va amal qilish qoidasi domen tilida belgilanadi: order:742:approval yoki seat:flight-21:12A kabi.
Texnik qulfdan farqi
Database row lock tranzaksiya davomida ma’lum satrni himoya qiladi va odatda connection uzilganda bo‘shaydi. Business lock esa bir nechta so‘rov, xizmat yoki inson ishtirok etadigan uzoq jarayon davomida yashashi mumkin. U database transactiondan tashqarida ham ma’no saqlaydi va foydalanuvchiga “obyekt tahrirlanmoqda” degan holatni ko‘rsatadi.
Optimistic yondashuv lock yaratmaydi: obyekt versioni o‘qiladi va update paytida o‘zgarmaganligi tekshiriladi. Konflikt kam bo‘lsa bu samarali. Pessimistic business lock esa konflikt xarajati yuqori bo‘lganda operatsiya boshlanishidan oldin ownership beradi. Tanlov contention, amal davomiyligi va foydalanuvchi tajribasiga bog‘liq.
Qulf yozuvi
Qulf registrida resource key, owner, yaratilgan vaqt, expiry va fencing token saqlanishi mumkin. Owner inson sessiyasi emas, aniq operation ID bo‘lgani ma’qul. Lease muddati jarayon qulab qolsa lock abadiy qolishining oldini oladi. Uzoq ish lease’ni heartbeat bilan yangilaydi, ammo tarmoq uzilishi paytida eski owner muddat tugaganini bilmasligi mumkin.
Fencing token har yangi lock olishda oshadigan raqamdir. Past token bilan kechikib kelgan eski yozuv downstream storage tomonidan rad etiladi. Faqat “men lockni oldim” tekshiruvi bunday stale owner muammosini hal qilmaydi. Unlock ham owner va tokenni atomik tekshiradi; boshqa jarayonning yangilangan qulfini tasodifan o‘chirmaydi.
Biznes qoidalari
Qulf doirasi juda keng bo‘lsa parallel ishlar keraksiz to‘xtaydi, juda tor bo‘lsa invariant himoyalanmaydi. Bir buyurtmaning tahriri bilan to‘lovi alohida yoki yagona lock talab qilishi domen qoidalaridan kelib chiqadi. Multiple resource lock kerak bo‘lsa barqaror tartib deadlock ehtimolini kamaytiradi.
Foydalanuvchi lock egasi, qolgan vaqt va amalni bekor qilish yo‘lini ko‘rishi mumkin. Administratorning force unlock amali audit qilinadi va haqiqiy jarayon holati tekshiriladi. Qulfni o‘chirib qo‘yish yakunlanmagan biznes operatsiyani avtomatik bekor qilmaydi.
Nosozlik sinovlari
Testlar parallel so‘rov, lease tugashi, clock skew, duplicate acquire, owner crash va delayed message holatini qamrab oladi. Metrikalar contention vaqti, lock soni, expiry va force unlockni ko‘rsatadi. Incidentda “lock ko‘p” alomatidan tashqari qaysi invariant va qaysi dependency jarayonni ushlab turgani aniqlanadi.
Holat mashinasi bilan bog‘lanish
Ba’zan alohida lock yozuvi o‘rniga biznes obyektining state transitioni mutual exclusion vazifasini bajaradi. Masalan, pending holatidan processingga compare-and-set bilan faqat bitta worker o‘tadi; qolganlari conflict oladi. Bu yondashuv lock va obyekt holatini ikki joyda sinxronlashtirish muammosini kamaytiradi. Uzoq inson tahririda esa draft branch yoki field-level merge to‘liq qulfdan qulayroq bo‘lishi mumkin. Lock tanlovi invariantni aniq ifodalashi kerak: “bir vaqtning o‘zida bitta operator” texnik talab emas, balki qaysi zararli parallel natijani oldini olishi tushuntiriladi. Shunda keraksiz serialization aniqlanadi.
Lock holati cache’dan emas, authoritative store’dan tekshiriladi. UI’dagi “band” belgisi kechikishi mumkin, yakuniy update esa serverdagi token va invariant bilan himoyalanadi.
Bog‘liq tushunchalar
Distributed lock, Lease, Fencing token, Optimistic concurrency, Pessimistic locking, Idempotency, Business invariant