Transaction Processing: September 27, 2005

Database Access For TP, represent database as a collection of named items. Read(X) - read database item X into local variable named X Write(X) - write local variable X’s value into database item X Update(X) - dangerous! May or may not be atomic! Granularity - the size of the data item. Large grain -- whole table, set of records, … Small grain -- … single record, set of fields within a record, single field.

Read(X) Find address of sector containing X Copy sector to buffer in main memory (unless already present) Copy item X from buffer into local variable X.

Write(X) Find address of sector containing X Copy that sector into buffer in memory Copy local variable X into correct location in buffer. Write buffer to disk.

ReadSet, WriteSet ReadSet -- the set of all items the transaction reads. WriteSet -- the set of all items the transaction writes.

Example transactions (Elmasri, et al) T1 T2read(x); x -= n;x += m;write(x); read(y); y += n; write(y); readSet(T1) = { x, y }readSet(T2) = {x} writeSet(T1) = { x, y }writeSet(T2) = {x}

Lost Update T1(transfer) T2 (deposit) read(x);//1read(x);//3 x -= n;//2x += m;//4 write(x);//5write(x);//7 read(y);//6 y += n;//8 write(y);//9 /* at //7, X has incorrect value because T1’s update is overwritten. */

Temporary Update (Dirty Read) T1(transfer) T2 (deposit) read(x);// 1read(x);// 4 x -= n;//2x += m;// 5 write(x);//3write(x);// 6 read(y);// 7 y += n; write(y); /* at // 4, reading uncommitted data at // 7, suppose T1 fails, then T1 must change x back; but T2 has already used, and written bad data!

Incorrect summary (aggregate) T1 (transfer) T3 read(x);// 4sum = 0;// 1 x -= n;// 5read(a);// 2 write(x);// 6sum += a;// 3 read(y);// y += n;// 12read(x);// 7 write(y);// 13sum += x;// 8 read(y);// 9 sum += y;// 10 /* at // 7, T3 reads x after n was subtracted, and reads y BEFORE n was added ==> sum is off by n. */

Unrepeatable read A transaction reads X two times. Between the two reads, a different transaction changes the value of X. (Violates Isolation)

System log (aka journal) System maintains a log that tracks all transaction operations affecting data values. Log used to recover from failure Log kept on disk, so not affected by many failure types. Log is periodically backed up to archival (tape) storage to allow recovery from disk failure.

Log records // T with system generated number // T#, has started execution. // T# has // changed value of DB item X. // T# has read value of item X. // T has completed; its effect can be // committed. // T# has been aborted.

Rollbacks Practically speaking,, is not used for rollbacks. Also, some recovery protocols do not require the newValue field of the write record. ALL changes to the data happen through transactions. Undo effects of write operations by tracing backward and restoring with oldValue’s. Sometimes, may need to redo (then we need those newValue’s)

Commit Point All operations accessing data have executed successfully AND the appropriate log records ( mostly) have been recorded in the log (the log written to disk). After the commit point, the transaction is committed. The system then writes the record

Rollback (undo) versus redo A transaction that has written (and ) but no to the log may have to be rolled back to undo the effects of the writes. A transaction that has written may have to have their changes to the data redone, by redoing the in the log.

Where is the log ? If the log is kept on disk only, then there will be multiple disk writes of the same log file sector. It is more efficient to write the log file buffer only when it fills up (just one write to disk). When the system crashes, only the log entries on the disk are used for recovery! So (to improve recovery), before a transaction reaches commit point, the part of the log not yet written to disk is force-written.

Schedule, History For n transactions, a schedule is the ordered list of operations on the data. Order of ops of a single transaction must be maintained. Order from > 1 transaction may be inteleaved. r 1 (x) means T1 reads x. W 2 (y) means T2 writes y a means abort c means commit

Schedule for lost update T1(transfer) T2 (deposit) read(x);//1read(x);//3 x -= n;//2x += m;//4 write(x);//5write(x);//7 read(y);//6 y += n;//8 write(y);//9 S lostUpdate = r1(x), r2(x), w1(x), r1(y), w2(x), w1(y)

Give the schedule for dirty read incorrect summary

Conflicting operations Two operations in a schedule conflict if: They belong to different transactions They access the same data element At least one is a write

S, is a complete schedule of n transactions if The operations in S are exactly those in T 1, … T n, including commit or abort For any pair of ops from the same T i, their order in S is the same as their order in T i For any two conflicting ops, one of the two must occur before the other in the schedule. I.e., for nonconflicting ops, a partial order is sufficient.

S is recoverable if Once a transaction is committed, it is never necessary to rollback T. S is recoverable if no transaction T in S commits until all transaction T’ that have written an item that T read have committed.

S: r1(x), r2(x), w1(x), r1(y), w2(x), c2, w1(y), c1 S is recoverable, even though it suffers from lost update.

S b : r 1 (x), w 1 (x), r 2 (x), r 1 (y), w 2 (x), c 2, a 1 Not recoverable: T2 reads x from T1, then t2 commits before T1 commits. Sc: r 1 (x), w 1 (x), r 2 (x), r 1 (y), w 2 (x), w 1 (y), c 1, c 2 Recoverable Sd: r 1 (x), w 1 (x), r 2 (x), r 1 (y), w 2 (x), w 1 (y), a 1, a 2 recoverable

Make three transactions, one deposits(commits), one withdraws(commits), one transfers (aborts). Give a recoverable schedule. Give a nonrecoverable schedule.