Sathya Peri, IIT Patna, India, sathya@mun

1. Efficient Non-Blocking Conflict Notion for Nested Transactions Sathya Peri, IIT Patna, India, sathya@mun.ca K.Vidyasankar, Memorial University, St John’s, Canada, vidya@mun.ca 1

2. Overview • Introduction to Closed Nested Transactions • Write and Read operations in closed nested transactions • lastWrite definition • Specification of lastWrite operations for read: • Blocking specifiction, lwSpec • Non-blocking specification, nblwSpec • Non-blocking Conflict notion 2

3. Nesting of Transactions • A transaction is nested: • if it invokes another transaction • Composing of transaction can be achieved through nesting • Composition: basis of modular programming • Different types of nesting: Closed, Open and Flat 3

4. Our Focus: Closed Nesting • We focus only on nested transactions with read and write operations • Let P be a parent transaction which invokes a sub-transaction S • In closed nesting, when the sub-transaction S commits • its effects are not visible to other 'external' transactions immediately, i.e., it is local • they become visible when its parent transaction P commits • Abort of the sub-transaction S has no affect on P 4

5. Illustration: Closed Nesting Closed Nesting Memory x=10 x=5 committed P Q read(x) = 5 committed read(x) = 10 S write(x,10) 5

6. Background Information: Schedule Representation tR • Schedule: r11(x) r211(y) w212(y) c21 w12(y) c1 r221(y) w222(z) c22 a2 r31(z) w32(b) c1 tfin tinit t2 t3 t1 t21 t22 r31(z) w32(b) w12(y) r11(x) r221(y) r211(y) w212(y) w222(z) 6

7. Write Operation – Lazy Write approach • A transaction maintains a local buffer for every data-item it writes to. • All the writes of a transaction are onto the local buffers. • When the transaction commits, the contents of the buffers are merged with its parent’s buffers. • On abort the buffers are discarded 7

8. Schedule Augmentation: Commit Writes • We augment a schedule with extra write operations: Commit Write operations • In a schedule, • There is a commit-write operation for every data-item, a committed (sub)transaction writes to • Aborted (sub) transactions do not have commit-write operations • A commit-write represents the merging of a write of a transaction on a data-item with its parent’s write • Simple memory write operation’s commit write is itself 8

9. Background Information: Schedule Representation tR • Augmented Schedule: r11(x) r211(y) w212(y) w21212(y) c21 w12(y) w112(y) c1 r221(y) w222(z) w22222(z) c22 a2 r31(z) w32(b) w332(b) c3 tfin tinit t2 t3 t1 t21 t22 r31(z) w32(b) w12(y) r11(x) r221(y) r211(y) w212(y) w222(z) 9

10. Observation on Write and Commit Operations • The write operation of a nested transaction ts involves only its local buffers • The commit of a sub-transaction ts with parent tp only involves the buffers of tp • Observation: Write and Commit operations be implemented atomically, possibly using locks 10

11. Read Operation – Closest Ancestor • A transaction performing a read operation on data-item d starts with its local write buffers. • If the data item is not present, then it • accesses the buffers of its ancestors in increasing order of height • reads from the buffers of an ancestor closest to it • A write operation read by a given read operation is denoted as the read’s lastWrite. 11

12. lastWrite Specification: Non-nested transactions • In single version database schedules, the lastWrite for a read operation ri(x) belonging to transaction ti is: • The previous closest write on the data-item x by a transaction ti, wj(x) • For instance consider the following schedule of non-nested transactions: r1(x) r2(x) w1(z) r2(y) w2(y) r1(z) w3(z) • lastWrite of r1(z) is w1(z) 12

13. lastWrite Specification: Nested transactions • In nested transactions, by reading from the closest ancestor the notion of lastWrite can be defined • The lastWrite of a read operation ri(x) in a nested transaction is either a simple write or committed write wj(x) which: • Occurs before the read • Is a peer of the read or the peer of an ancestor of the read • Is closest in terms of tree height • Is closest in terms of schedule distance • We denote this specification of lastWrite as lwSpec 13

14. Examples of LastWrite using lwSpec tR • r11(x) : init(x), r211(y):init(y), r221(y):w21212(y) r31(z):init(z) tfin tinit t2 t3 t1 t21 t22 r31(z) w32(b) w12(y) r11(x) r221(y) r211(y) w212(y) w222(z) 14

15. Limitations of lwSpec • lwSpec implicitly assumes that the read operations are atomic • Specifically, it assumes that no other operation is being executed when a read is in progress • A read operation that follows closest ancestor option, involves buffers of multiple transactions • Hence can not be implemented atomically • Each read operation is represented as a leaf node in the tree • To correctly capture the read, we assume that the node implies the instant the read completes 15

16. Limitations of lwSpec: illustration • Consider a nested transaction ti at level 10 (in the tree) wishing to read x,ri(x). Consider this sequence • When the control (of the read) reaches a transaction tj at level 9, it does not find any buffer for x • The control goes to transaction tk at level 8 and still does not find x. At that point suppose transaction tj writes to x • The control finally reaches a transaction tj at level 7 and reads x • This implies that the last two conditions of the lwSpec are not true. 16

17. Non-blocking lastWrite Specification: nblwSpec • The lastWrite of a read operation ri(x) in a nested transaction is either a simple write or committed write wj(x) which: • Occurs before the read • Is a peer of the read or the peer of an ancestor of the read • We denote this specification of lastWrite as nblwSpec • It must be noted that given a schedule, for a given read ri(x), • there could be multiple writes in the schedule that satisfy the nblwSpec(unlike lwSpec, where there is only one write) • thus, in this case an external entity should specify the lastWrite for each read operation 17

18. lastWrite Specification and Conflict notion • Based on the specification of the lastWrite, the correctness for the correctness criteria can be defined • Two data operations on the same data-item are conflicting: • if one of them is a write operation • Then, based on the correctness criteria, accurate conflict notions can be defined • Using accurate conflict notion, efficient algorithms can be devised • Similar to Conflict Serializability in databases 18

19. External Reads • For a transaction, we define • External-read: A read operation belonging to a descendant, whose lastWrite is external to the transaction • A simple-memory read is an external read of itself 19

20. Non-blocking Conflict Notion • For any two nodes (transactions/simple memory operations) in the tree na and nb, which contain two operations oa and ob are in conflict if: • w-w conflict: oa and ob are commit-writes respectively wa and wb • w-r conflict: oa is a commit-write of na, wa and ob is an external read of nb, rb. • r-w conflict: oa is an external-read of na, raand ob is a commit-write of nb,wb.Let the lastWrite of ra be wl. This conflict is true if S.ord(wl) < S.ord(wb) and S.level(wl) < S.level(wb) 20

21. Conclusion • Characterized the non-blocking specification of lastWrites, nblwSpec • Developed conflict notions based on these non-blocking specification 21

22. Questions? 22