1 / 22

Efficient Non-Blocking Conflict Notion for Nested Transactions

This paper introduces closed nested transactions, focusing on write and read operations, lastWrite definitions, and non-blocking conflict notions. It discusses nesting of transactions, composition methods, and types of nesting. The focus is on closed nesting, where sub-transaction effects are visible only after the parent transaction commits. Illustrations and schedule representations are provided, along with lazy write approaches, schedule augmentations, and observations on write and commit operations. LastWrite specifications for non-nested and nested transactions are explored, with examples and limitations discussed.

omeagher
Download Presentation

Efficient Non-Blocking Conflict Notion for Nested Transactions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related