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

2. Overview 2 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

3. Nesting of Transactions 3 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

4. Our Focus: Closed Nesting 4 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

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

6. Background Information: Schedule Representation Schedule: r 11 (x) r 211 (y) w 212 (y) c 21 w 12 (y) c 1 r 221 (y) w 222 (z) c 22 a 2 r 31 (z) w 32 (b) c 1 6 tRtR t1t1 t2t2 t3t3 t 21 t 22 r 211 (y)w 212 (y) r 221 (y) w 222 (z) w 32 (b) r 31 (z) r 11 (x) w 12 (y) t init t fin

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 Augmented Schedule: r 11 (x) r 211 (y) w 212 (y) w 21 212 (y) c 21 w 12 (y) w 1 12 (y) c 1 r 221 (y) w 222 (z) w 22 222 (z) c 22 a 2 r 31 (z) w 32 (b) w 3 32 (b) c 3 9 tRtR t1t1 t2t2 t3t3 t 21 t 22 r 211 (y)w 212 (y) r 221 (y) w 222 (z) w 32 (b) r 31 (z) r 11 (x) w 12 (y) t init t fin

10. Observation on Write and Commit Operations The write operation of a nested transaction t s involves only its local buffers The commit of a sub-transaction t s with parent t p only involves the buffers of t p 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 r i (x) belonging to transaction t i is: The previous closest write on the data-item x by a transaction t i, w j (x) For instance consider the following schedule of non-nested transactions: r 1 (x) r 2 (x) w 1 (z) r 2 (y) w 2 (y) r 1 (z) w 3 (z) lastWrite of r 1 (z) is w 1 (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 r i (x) in a nested transaction is either a simple write or committed write w j (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 r 11 (x) : init(x), r 211 (y):init(y), r 221 (y): w 21 212 (y) r 31 (z):init(z) 14 tRtR t1t1 t2t2 t3t3 t 21 t 22 r 211 (y)w 212 (y) r 221 (y) w 222 (z) w 32 (b) r 31 (z) r 11 (x) w 12 (y) t init t fin

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 t i at level 10 (in the tree) wishing to read x, r i (x). Consider this sequence When the control (of the read) reaches a transaction t j at level 9, it does not find any buffer for x The control goes to transaction t k at level 8 and still does not find x. At that point suppose transaction t j writes to x The control finally reaches a transaction t j 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 r i (x) in a nested transaction is either a simple write or committed write w j (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 r i (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 n a and n b, which contain two operations o a and o b are in conflict if: w-w conflict: o a and o b are commit-writes respectively w a and w b w-r conflict: o a is a commit-write of n a, w a and o b is an external read of n b, r b. r-w conflict: o a is an external-read of n a, r a and o b is a commit-write of n b,w b.Let the lastWrite of r a be w l. This conflict is true if S.ord(w l ) < S.ord(w b ) and S.level(w l ) < S.level(w b ) 20

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

22. Questions? 22