Conditional write — record faqat oldindan belgilangan shart joriy holatda bajarilsa yoziladigan operatsiyadir. U read–modify–write orasidagi race conditionni database yoki storage darajasida atomar tekshiradi. Shart version tengligi, obyekt mavjud emasligi, qiymat diapazoni yoki compare-and-set ko‘rinishida bo‘lishi mumkin.
Optimistic concurrency
Record version=7 bilan o‘qiladi. Mijoz update yuborganda WHERE id=? AND version=7 shartini qo‘shib, yangi versionni 8 qiladi. Boshqa yozuvchi oldin o‘zgartirgan bo‘lsa affected row nol bo‘ladi. Mijoz yangi holatni o‘qib, foydalanuvchi bilan merge qiladi yoki amalni qayta hisoblaydi.
HTTP ETag va If-Match ayni semantikani APIga olib chiqadi. If-None-Match: * obyekt faqat mavjud bo‘lmasa yaratilishini talab qiladi. ETag response representationga bog‘liq bo‘lsa, server canonical versionni to‘g‘ri tanlaydi. Weak ETag write precondition uchun har doim yetarli emas.
Database operatorlari
SQL update shartni bitta statementda tekshiradi. Unique constraint “faqat yo‘q bo‘lsa insert” race ni hal qiladi; avval SELECT, keyin INSERT ikki clientda bir vaqtda muvaffaqiyatli ko‘rinishi mumkin. INSERT ... ON CONFLICT yoki MERGE platforma semantikasiga ko‘ra insert/updateni atomar boshqaradi.
Dynamo uslubidagi omborda condition expression atribut mavjudligi yoki qiymatini tekshiradi. Cassandra lightweight transaction Paxos orqali IF NOT EXISTS va compare shartini beradi. Bunday operatsiya oddiy eventual writega qaraganda ko‘proq round trip va contention talab qiladi.
Biznes invariantlari
“Balans yetarli bo‘lsa kamaytir” bitta recordda conditional update bilan bajarilishi mumkin: balance >= amount. Ammo balans va boshqa jadvaldagi limit birgalikda tekshirilsa transaction kerak. Alohida conditional writelar ko‘p record invariantini atomar qilmaydi.
Inventoryda quantity = quantity - n WHERE quantity >= n oversellingni cheklaydi. Muvaffaqiyat affected row orqali aniqlanadi. Keyin tashqi payment chaqiruvi xato bo‘lsa kompensatsiya yoki saga talab qilinadi; database sharti tashqi tizimni tranzaksiyaga kiritmaydi.
Timeout va retry
Client timeout olganda write serverda commit bo‘lgan bo‘lishi mumkin. Ayni condition bilan retry ba’zan xavfsiz: version allaqachon o‘zgargan bo‘lsa rad etiladi. Lekin increment sharti va yangi request sifatida yuborilsa ikki marta qo‘llanishi mumkin. Idempotency key operation natijasini saqlaydi.
Conditional failure texnik xato emas, normal konflikt bo‘lishi mumkin. API 409 yoki 412 kabi holat, joriy version va qayta urinish siyosatini beradi. Kuchli contentionda retry storm yuz beradi; random backoff, queue yoki pessimistic lock samaraliroq bo‘lishi mumkin.
Kuzatuv
Success, condition-failed, timeout, retry va conflict keylar metrikasi ajratiladi. Condition failure oshishi parallel tahrir yoki stale client signalidir. Audit shartning maxfiy qiymatini oshkor qilmasdan expected version va operation IDni saqlaydi. Conditional write correctnessni soddalashtiradi, ammo transaction isolation va access controlning o‘rnini bosmaydi.
Qayta urinish
Shart bajarilmaganda mijoz yangi holatni o‘qib, o‘zgarishni qayta hisoblash yoki foydalanuvchiga ziddiyatni ko‘rsatish haqida qaror qiladi. Ko‘r-ko‘rona cheksiz retry yuqori raqobatda server yukini oshiradi. Cheklangan urinish, tasodifiy backoff va idempotent operatsiya birgalikda tizimni barqarorroq qiladi.
Conditional write biznes invariantini himoya qilsa, shart va yangilanish bir xil atomar operatsiyada bajarilishi kerak. Alohida tekshiruv keyin yozish race conditionni qayta keltirib chiqaradi.
Bog‘liq tushunchalar
Compare-and-set, Optimistic concurrency control, ETag, Atomic operation, Idempotency, Transaction, Version field