En databasetransaksjon grupperer flere operasjoner slik at de enten lykkes alle eller mislykkes alle sammen (atomicitet) — og forhindrer delvis, inkonsistente oppdateringer. Django tilbyr transaction.atomic for å omslå operasjoner i en transaksjon, og sikrer dataintegritet for flertrinns-operasjoner.
():
from_account.balance -= amount
from_account.save()
to_account.balance += amount
to_account.save()
Uten en transaksjon, hvis den andre operasjonen mislykkes, har den første allerede blitt gjennomført — og etterlater databasen i en brutt, inkonsistent tilstand (penger trukket fra, men ikke overført til).
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
Inni atomic(), hvis noen operasjon kaster et unntak, tilbakestiller Django hver endring i blokken — så databasen blir aldri liggende halvoppdatert. Ved suksess committed alle endringer sammen.
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
Nestede atomic-blokker bruker savepoints — den indre blokken kan tilbakestilles uavhengig uten å avbryte hele den ytre transaksjonen.
✓ 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
Databasetransaksjoner er essensielle for dataintegritet når en operasjon involverer flere relaterte databaseendringer som må lykkes eller mislykkes som en enhet — og å forstå transaction.atomic er viktig kunnskap for å bygge korrekte, pålitelige applikasjoner.
Kjerneproblemstillingen som transaksjoner løser er delvis feil: uten atomicitet, hvis en flertrinns-operasjon mislykkes halvveis (et krasj, et unntak, en begrensningsbrudd), blir databasen liggende i en inkonsistent tilstand — det klassiske pengeoverføringseksemplet (trukket fra en konto, men ikke overført til en annen) illustrerer hvordan dette korrumperer data og kan ha alvorlige konsekvenser. transaction.atomic gir garantien om at operasjoner er alt eller ingenting (tilbakestiller hele blokken ved enhver feil), noe som er nødvendig for enhver operasjon som spenner over flere skrivinger — opprett en ordre med dens linjeposter, overføring av midler, oppdatering av relaterte poster — for å opprettholde en konsistent database.
Å forstå hvordan man bruker atomic-blokker (som en kontekstbehandler eller dekoratør), nestede transaksjoner med savepoints, og viktige detaljer — å fange unntak utenfor blokken, bruke select_for_update() for å låse rader og forhindre racingbetingelser i samtidige oppdateringer, og holde transaksjoner korte for å unngå å holde låser — er praktisk kunnskap for å bygge robuste applikasjoner.
Datakonsistens er et grunnleggende krav for pålitelige systemer, og transaksjoner er mekanismen som sikrer det for flertrinns-databaseoperasjoner, noe som gjør dette til et viktig tema som skiller utviklere som skriver korrekt, integritetsbevaring-kode fra de hvis applikasjoner kan stille korruptere data under feilebetingelser eller samtidsaksess — et ofte relevant problem i enhver applikasjon som håndterer viktige, relaterte dataendringer.