एक डेटाबेस ट्रान्जेक्शन अनेक ऑपरेशन्स गटबद्ध करते जेणेकरून ते सर्व यशस्वी किंवा सर्व अपयशी एकत्रितपणे (atomicity) होतात — आंशिक, असंगत अपडेट्स प्रतिबंधित करते. Django transaction.atomic प्रदान करते ज्यामुळे ऑपरेशन्स ट्रान्जेक्शनमध्ये गुंडाळू शकतात, बहु-चरण ऑपरेशन्सेसाठी डेटा अखंडता सुनिश्चित करते.
():
from_account.balance -= amount
from_account.save()
to_account.balance += amount
to_account.save()
ट्रान्जेक्शन न करता, जर दुसरा ऑपरेशन अपयशी होत, तर पहिला आधीच कमिट होत — डेटाबेसला एक तुटलेल्या, असंगत स्थितीत सोडत (पैसे डेबिट केले जातात परंतु क्रेडिट केले जात नाहीत).
from django.db import transaction
# as a context manager
def transfer_money(from_account, to_account, amount):
with transaction.atomic(): # everything inside is ONE transaction
from_account.balance -= amount
from_account.save()
to_account.balance += amount
to_account.save()
# if ANY operation raises an exception, the WHOLE block is ROLLED BACK
# → either both saves happen, or neither does (atomicity)
# or as a decorator on a whole function/view
@transaction.atomic
def create_order(request):
order = Order.objects.create(...)
for item in items:
OrderItem.objects.create(order=order, ...)
# all-or-nothing: a failure anywhere rolls back the entire order creation
atomic() मध्ये, जर कोणताही ऑपरेशन अपवाद उत्तेजित करत, तर Django ब्लॉकमधील प्रत्येक बदल रोल्बॅक करते — तर डेटाबेस अर्धांकित कधीही सोडले जात नाही. यशस्वीतेवर, सर्व बदल एकत्रितपणे कमिट होतात.
with transaction.atomic(): # outer transaction
do_something()
try:
with transaction.atomic(): # inner = a SAVEPOINT
risky_operation()
except Exception:
pass # inner rolls back to the savepoint; outer continues
नेस्टेड atomic ब्लॉक्स savepoints वापरतात — आतील ब्लॉक संपूर्ण बाह्य ट्रान्जेक्शन अॅबर्ट न करता स्वतंत्रपणे रोल्बॅक करू शकतात.
✓ Catch exceptions OUTSIDE the atomic block (catching inside can break rollback handling)
✓ select_for_update() locks rows within a transaction (prevent race conditions on updates)
with transaction.atomic():
account = Account.objects.select_for_update().get(pk=id) # row locked until commit
✓ ATOMIC_REQUESTS setting wraps EVERY request in a transaction (per-database)
✓ Keep transactions SHORT — long transactions hold locks, hurting concurrency
डेटाबेस ट्रान्जेक्शन्स डेटा अखंडतासाठी आवश्यक आहेत जेव्हा ऑपरेशन अनेक संबंधित डेटाबेस बदल समाविष्ट करते जे यशस्वी किंवा अपयशी हवे एकक म्हणून — आणि transaction.atomic समजून घेणे योग्य, विश्वसनीय ऍप्लिकेशन्स बांधण्यासाठी महत्वाचे ज्ञान आहे.
ट्रान्जेक्शन्स सोडवत असलेली मुख्य समस्या आंशिक अपयश आहे: अणुत्व न करता, जर बहु-चरण ऑपरेशन अर्धांतून अपयशी होत (क्रॅश, अपवाद, कंस्ट्रेंट उल्लंघन), डेटाबेस असंगत स्थितीत सोडले जाते — शास्त्रीय पैसे-हस्तांतरण उदाहरण (एक खात्यातून डेबिट केले परंतु दुसर्यास क्रेडिट केले नाही) कसे हे डेटा भ्रष्ट करते आणि गंभीर परिणाम असू शकतात ते दर्शवते. transaction.atomic सर्व-किंवा-काही नाही ची हमी देते (कोणत्याही अपयशावर संपूर्ण ब्लॉक रोल्बॅक करून), जी अनेक लेखन विस्तारणार्या कोणत्याही ऑपरेशनसाठी आवश्यक आहे — ऑर्डर त्याच्या लाइन आयटम्ससह तयार करणे, निधी हस्तांतरित करणे, संबंधित रेकॉर्ड अपडेट करणे — सुसंगत डेटाबेस राखण्यासाठी.
अटॉमिक ब्लॉक्स कसे वापरायचे (context manager किंवा decorator म्हणून), savepoints सह नेस्टेड ट्रान्जेक्शन्स, आणि महत्वाची तपशीलें — ब्लॉकच्या बाहेर अपवाद पकडणे, select_for_update() वापरून पंक्तीची लॉक करणे आणि समवर्ती अपडेट्समध्ये रेस कंडीशन्स प्रतिबंधित करणे, आणि ट्रान्जेक्शन्स लॉक धारण करणे टाळण्यासाठी छोटे ठेवणे — मजबूत ऍप्लिकेशन्स बांधण्यासाठी व्यावहारिक ज्ञान आहे.
डेटा सुसंगतता विश्वसनीय सिस्टम्सची मूलभूत आवश्यकता आहे, आणि ट्रान्जेक्शन्स हे बहु-चरण डेटाबेस ऑपरेशन्सेसाठी हमी देणारी यंत्रणा आहे, हे एक महत्वाचा विषय बनवते जो योग्य, अखंडता-संरक्षण कोड लिहिणार्या विकासकर्त्यांना त्यांच्या ऍप्लिकेशन्स अपयशच्या परिस्थितीत किंवा समवर्ती प्रवेशाखाली डेटा गूंगावेड नष्ट करू शकतात असे विकासकर्त्यांपासून वेगळे करते — महत्वाचे, संबंधित डेटा बदल हाताळणार्या कोणत्याही ऍप्लिकेशनमध्ये वारंवार प्रासंगिक समस्या.
सविस्तर उत्तरांसह IT मुलाखत प्रश्नांचे ग्रंथालय — Junior पासून Senior पर्यंत.
देणगी द्या