Please enable JavaScript.
Coggle requires JavaScript to display documents.
Transaction (TXN) Management I - Coggle Diagram
Transaction (TXN) Management I
Transactions
DBMS Memory Model
Global: main memory
Disk
Local: process
Collection of operations/statements form a single atomic logical unit
Operations: read/write
all or nothing
e.g. transfer $, buy group of products, register class
Why?
Recovery & Durability
consistent, durable when crash/user abort
stored in full or not at all
keep
log
to enable
roll-back
TXNs
Concurrency
parallelize TXNs without inconsistencies, multi-thread
good DBMS performance
provides illusion of single-user system:
isolation
maintains
consistency
during concurrent execution
ACID
Atomicity
all or none actions in TXN happens
Outcomes
commit
: changes are made
abort
: no changes are made
Consistency
consistent DBMS remains consistent after TXN
programmer: TXN takes a consistent state to a consistent state
DBMS: TXN is atomic
Isolation
execution of one TXN is isolated from others (may interleaved)
if T1, T2 interleaved, result should be same as T1->T2 or T2->T1
Durability
if transaction
commits
, its effects persist
write to disk or write log to disk
Logging
Why?
memory constraints: buffer pool want to write to disk early
time constraint: one TXN takes very long
Log
a list of modifications,
REDO/UNDO for every update, diff written to log
in memory -> duplexed and archieved on disk
force pages to disk
<TXNID, location, old-data, new-data>
Write-Ahead Logging (WAL)
Atomicity:
Force
log
record for an update to
disk
before the page goes to disk =>
UNDO
using log
Durability:
Write to
disk
all
log records
for a TXN before commit
=> REDO using log, if crash after commit
Has to force multiple pages (logs) to disk
ARIES: complex recovery algorithm to improve performance