Atomicity — transaction ichidagi amallar yagona bo‘linmas birlik sifatida bajarilishini bildiradigan ACID xususiyati. Transaction muvaffaqiyatli commit qilinsa uning barcha o‘zgarishlari qabul qilinadi; abort yoki xato yuz bersa bajarilgan qismi ham bekor qilinadi. Tashqi kuzatuvchi transactionning yarim yakunlangan holatini doimiy natija sifatida ko‘rmasligi kerak.
Transaction chegarasi
Bank o‘tkazmasida bir hisobdan mablag‘ kamaytirilib, boshqasiga qo‘shiladi. Ikkinchi yangilash muvaffaqiyatsiz bo‘lsa birinchi o‘zgarish ham rollback qilinadi. Atomicity biznes amali avtomatik to‘g‘ri degani emas: balansni noto‘g‘ri hisoblaydigan ikki statement ham birga commit bo‘lishi mumkin. U faqat belgilangan transaction chegarasidagi “hammasi yoki hech biri” natijasini beradi.
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 10;
UPDATE accounts SET balance = balance + 100 WHERE id = 20;
COMMIT;
Xato aniqlansa COMMIT o‘rniga ROLLBACK bajariladi. Constraint buzilishi yoki deadlock ham transactionni abort qilishi mumkin.
Amalga oshirish mexanizmlari
Database atomicity’ni write-ahead log, undo record yoki multi-version mexanizmi yordamida ta’minlaydi. O‘zgartiriladigan data page diskka yozilishidan oldin uni tiklash uchun zarur log barqaror storage’ga yetkaziladi. Recovery restart vaqtida commit qilinmagan ishni undo qiladi yoki commit qilingan, ammo data page’ga yetmagan ishni redo qiladi.
Copy-on-write storage yangi bloklarni alohida yozib, root pointer’ni atomar almashtirishi mumkin. Qaysi mexanizm ishlatilishidan qat’i nazar, checksum, yozuv tartibi va flush semantikasi quvvat uzilishida ham yakuniy holatni ajratishga xizmat qiladi.
Savepoint va nested ish
Savepoint transaction ichida qisman qaytish nuqtasini belgilaydi. U butun transaction atomicity’sini buzmaydi: savepointgacha qaytgan ishlar keyinchalik umumiy commit bilan tasdiqlanadi yoki umumiy rollback bilan bekor bo‘ladi. “Nested transaction” turli DBMSlarda haqiqiy mustaqil commit bermasligi mumkin.
Taqsimlangan transaction
Bir transaction ikki mustaqil database yoki message brokerga tegsa, bitta lokal log yetarli emas. Two-phase commit ishtirokchilardan avval tayyor holatni, keyin umumiy commit yoki abort qarorini talab qiladi. Coordinator uzilganda prepared participant qarorni kutib resurslarni ushlab turishi mumkin.
Microservice tizimida ko‘pincha global atomicity o‘rniga outbox, idempotency va compensation ishlatiladi. Saga’dagi compensation oldingi biznes amalini mantiqan teskari qiladi, ammo vaqtni orqaga qaytaradigan haqiqiy database rollback emas; oraliq holatlar kuzatilishi mumkin.
Atomic operationdan farqi
CPU atomic instruction yoki compare-and-swap bitta xotira o‘zgarishini bo‘linmas qiladi. Database transaction esa ko‘plab statement, page va log recordlarini qamrab oladi. Faylni atomic rename qilish ham faqat nom almashtirish nuqtasiga tegishli. Har uch holatda “atomic” so‘zi bo‘linmas kuzatilish g‘oyasini saqlaydi, lekin kafolat chegarasi boshqa.
Xatolar va tashqi ta’sir
Transaction rollback qilinganda yuborilgan email, HTTP chaqirig‘i yoki tashqi fayl yozuvi avtomatik qaytmaydi. Bunday side effect commitdan keyin ishonchli queue orqali bajariladi yoki idempotent consumer bilan muvofiqlashtiriladi. Aks holda database abort bo‘lsa ham tashqi tizim amalni ko‘rishi mumkin.
DDL va fayl chegaralari
Schema o‘zgarishining transaction ichida atomic bajarilishi barcha DBMSlarda bir xil emas. Ayrim tizim CREATE TABLE yoki ALTER TABLEni rollback qiladi, ayrimlari implicit commit bajarishi mumkin. Katta fayl importi ham database transactioniga faqat satrlar yozilgan qismda kiradi; source faylning ko‘chirilishi alohida amal bo‘lib qoladi. Kafolat chegarasi aniq aniqlanmasa “atomic” so‘zi ortiqcha keng talqin qilinadi.
Bog‘liq tushunchalar
ACID, Transaction, Commit, Rollback, Write-ahead log, Savepoint, Two-phase commit, Outbox pattern