Savepoint — ochiq database transaction ichida keyinchalik qisman rollback qilish mumkin bo‘lgan nomlangan nuqta. U transactionni yakunlamaydi va o‘zgarishlarni boshqa sessionlarga commit qilmaydi. Savepointdan keyingi amallar bekor qilinib, undan oldingi amallar transaction ichida saqlab qolinishi mumkin.
Asosiy ishlash tartibi
Quyidagi misolda ikkinchi bosqich xato bersa faqat shu bosqichdan keyingi ish qaytariladi:
BEGIN;
UPDATE orders SET status = 'processing' WHERE id = 42;
SAVEPOINT before_inventory;
UPDATE inventory SET quantity = quantity - 1 WHERE product_id = 7;
ROLLBACK TO SAVEPOINT before_inventory;
COMMIT;
Yakuniy COMMIT birinchi yangilashni tasdiqlaydi. Agar butun transaction ROLLBACK qilinsa savepointdan oldingi o‘zgarish ham bekor bo‘ladi.
Nomlash va release
Bir transactionda bir nechta savepoint yaratilishi mumkin. Bir xil nom qayta ishlatilsa oldingi nuqta almashtirilishi yoki stackga o‘xshash semantika qo‘llanishi DBMSga bog‘liq. RELEASE SAVEPOINT nuqtani olib tashlaydi; bu commit emas. Ba’zi tizimlarda keyingi savepointlar oldingi nuqtaga rollback qilinganda avtomatik yo‘qoladi.
Transaction commit yoki to‘liq rollback qilinganda barcha savepointlar tugaydi. Ular connection uzilishidan keyin tiklanadigan doimiy obyekt emas.
Xatolarni qayta ishlash
Stored procedure bir necha mustaqil satrni qayta ishlaganda har element oldidan savepoint yaratishi mumkin. Bitta element constraint buzsa shu qism qaytarilib, boshqalari davom etadi. Biroq har xatoni yutib yuborish noto‘g‘ri natijani yashiradi; qaytarilgan element va sabab audit qilinadi.
Ayrim database xatolari faqat statementni bekor qiladi, ayrimlari esa butun transactionni “aborted” holatiga o‘tkazadi. Bunday holatda savepointga rollback transactionni yana ishlaydigan holatga keltirishi mumkin yoki keltirmasligi vendor semantikasiga bog‘liq. Deadlock qurboni bo‘lgan transaction ko‘pincha to‘liq qayta boshlanadi.
Frameworklarda nested transaction
Application framework nested transaction API’sini savepoint orqali amalga oshirishi mumkin. Ichki blokdagi “commit” faqat savepointni release qiladi; tashqi transaction keyinchalik rollback qilinsa barcha o‘zgarishlar yo‘qoladi. Haqiqiy mustaqil transaction alohida connection talab qilishi mumkin va isolation oqibatlari boshqacha bo‘ladi.
ORM savepoint nomlarini avtomatik boshqaradi. Raw SQL va framework transaction manager aralashtirilsa managerning ichki holati database holatidan ajralib qolmasligi kerak.
Resurs va cheklovlar
Savepoint rollback uchun undo yoki eski row versionlarini saqlash muddatini uzaytirishi mumkin. Juda uzoq transaction lock, version store va log truncationga bosim beradi. Ko‘p savepointning metadata xarajati kichik bo‘lsa ham, ular uzoq transactionni zararsiz qilib qo‘ymaydi.
External side effect savepoint bilan qaytmaydi. Transaction ichida yuborilgan HTTP so‘rovi yoki email allaqachon tashqi tizimga yetgan bo‘lishi mumkin. Bunday ish commitdan keyingi queue yoki outbox orqali ajratiladi.
Bulk importdagi qo‘llanish
Katta importda har yozuvdan oldin savepoint olish yaroqsiz satrni tashlab, qolganlarini davom ettirishga imkon beradi. Bu yondashuv “qisman muvaffaqiyat” semantikasini beradi: caller nechta satr qabul qilingani va qaysilari rad etilganini oladi. Barcha fayl bitta atomic birlik bo‘lishi kerak bo‘lsa bitta xato butun transactionni rollback qiladi.
Savepoint soni ko‘paygani sari exception oqimi va test holatlari murakkablashadi. Import formatini oldindan validatsiya qilish database ichidagi rollback xarajatini kamaytiradi, lekin concurrency sabab yuz beradigan unique conflict faqat yozish vaqtida aniq bo‘ladi.
Locklarga ta’siri
Savepointga rollback qilinganda undan keyin olingan locklar chiqarilishi mumkin, ammo ayrim lock yoki escalation transaction oxirigacha qolishi DBMSga bog‘liq. Shu sababli qisman rollback bloklanishni albatta tugatadi deb taxmin qilinmaydi. Lock jadvali va vendor semantikasi bilan tekshiriladi.
Bog‘liq tushunchalar
Transaction, Rollback, Commit, Atomicity, Nested transaction, Stored procedure, Undo log, Outbox pattern