Django में database transactions कैसे काम करते हैं?

Question

Accepted Answer

एक **database transaction** कई operations को समूहित करता है ताकि वे या तो **सभी सफल हों या सभी एक साथ विफल हों** (atomicity) — partial, inconsistent updates को रोकते हुए। Django operations को एक transaction में wrap करने के लिए `transaction.atomic` प्रदान करता है, multi-step operations के लिए data integrity सुनिश्चित करते हुए।

## जिस समस्या को transactions हल करते हैं

```python
# ❌ WITHOUT a transaction — partial failure leaves inconsistent data
def transfer_money(from_account, to_account, amount):
    from_account.balance -= amount
    from_account.save()                  # ✓ succeeds
    # ...if the server crashes HERE, money vanished from one account...
    to_account.balance += amount
    to_account.save()                    # ✗ never runs → money LOST!
```

एक transaction के बिना, यदि दूसरा operation विफल हो जाता है, तो पहला पहले ही commit हो चुका है — database को एक broken, inconsistent state में छोड़ते हुए (पैसा debited लेकिन credited नहीं)।

## transaction.atomic — all-or-nothing

```python
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)
```

```python
# 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()` के अंदर, यदि कोई operation एक exception raise करता है, तो Django block में प्रत्येक change को **roll back** कर देता है — इसलिए database कभी half-updated नहीं छूटता। सफलता पर, सभी changes एक साथ commit होते हैं।

## nested atomic blocks (savepoints)

```python
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
```

Nested `atomic` blocks savepoints का उपयोग करते हैं — inner block पूरे outer transaction को abort किए बिना स्वतंत्र रूप से roll back हो सकता है।

## महत्वपूर्ण विवरण

```text
✓ 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
```

## यह क्यों महत्वपूर्ण है

Database transactions **data integrity** के लिए आवश्यक हैं जब भी एक operation कई संबंधित database changes को शामिल करता है जिन्हें एक unit के रूप में सफल या विफल होना चाहिए — और `transaction.atomic` को समझना correct, reliable applications बनाने के लिए महत्वपूर्ण ज्ञान है।

जिस मुख्य समस्या को transactions हल करते हैं वह है **partial failure**: atomicity के बिना, यदि एक multi-step operation बीच में विफल हो जाता है (एक crash, एक exception, एक constraint violation), तो database एक inconsistent state में छूट जाता है — classic money-transfer उदाहरण (एक account से debited लेकिन दूसरे को credited नहीं) दर्शाता है कि यह कैसे data को corrupt करता है और गंभीर परिणाम दे सकता है। `transaction.atomic` यह guarantee प्रदान करता है कि operations **all-or-nothing** हैं (किसी भी failure पर पूरे block को roll back करते हुए), जो किसी भी operation के लिए आवश्यक है जो कई writes को फैलाता है — अपने line items के साथ एक order बनाना, funds transfer करना, संबंधित records को update करना — एक consistent database बनाए रखने के लिए।

Atomic blocks (एक context manager या decorator के रूप में), savepoints के साथ nested transactions, और महत्वपूर्ण विवरण — block के *बाहर* exceptions catch करना, concurrent updates में race conditions को रोकने के लिए rows को lock करने के लिए **`select_for_update()`** का उपयोग करना, और locks को hold करने से बचने के लिए transactions को छोटा रखना — को कैसे उपयोग करें यह समझना robust applications बनाने के लिए व्यावहारिक ज्ञान है।

Data consistency reliable systems की एक मौलिक आवश्यकता है, और transactions वह mechanism हैं जो इसे multi-step database operations के लिए सुनिश्चित करता है, जो इसे एक महत्वपूर्ण विषय बनाता है जो उन developers को अलग करता है जो correct, integrity-preserving code लिखते हैं उनसे जिनकी applications failure conditions या concurrent access में चुपचाप data corrupt कर सकती हैं — किसी भी application में जो महत्वपूर्ण, संबंधित data changes को handle करती है, एक अक्सर प्रासंगिक चिंता।