sathya peri, iit patna, india, sathya@mun

Download Sathya Peri, IIT Patna, India,  sathya@mun

Post on 01-Jan-2016

45 views

Category:

Documents

2 download

Embed Size (px)

DESCRIPTION

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. Overview. Introduction to Closed Nested Transactions Write and Read operations in closed nested transactions - PowerPoint PPT Presentation

TRANSCRIPT

  • Sathya Peri, IIT Patna, India, sathya@mun.caK.Vidyasankar, Memorial University, St Johns, Canada, vidya@mun.ca*Efficient Non-Blocking Conflict Notion for Nested Transactions

  • Overview*Introduction to Closed Nested TransactionsWrite and Read operations in closed nested transactionslastWrite definitionSpecification of lastWrite operations for read:Blocking specifiction, lwSpecNon-blocking specification, nblwSpecNon-blocking Conflict notion

  • Nesting of Transactions*A transaction is nested: if it invokes another transaction Composing of transaction can be achieved through nestingComposition: basis of modular programmingDifferent types of nesting: Closed, Open and Flat

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

  • Illustration: Closed Nesting*Memoryx=5PSQClosed Nestingx=10write(x,10)read(x) = 5read(x) = 10committedcommitted

  • Background Information: Schedule Representation

    Schedule: r11(x) r211(y) w212(y) c21 w12(y) c1 r221(y) w222(z) c22 a2 r31(z) w32(b) c1 *tRt1t2t3t21t22r211(y)w212(y)r221(y)w222(z)w32(b)r31(z)r11(x)w12(y)tinittfin

  • Write Operation Lazy Write approachA 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 parents buffers. On abort the buffers are discarded*

  • Schedule Augmentation: Commit WritesWe augment a schedule with extra write operations: Commit Write operationsIn a schedule, There is a commit-write operation for every data-item, a committed (sub)transaction writes toAborted (sub) transactions do not have commit-write operationsA commit-write represents the merging of a write of a transaction on a data-item with its parents writeSimple memory write operations commit write is itself *

  • Background Information: Schedule Representation

    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

    *tRt1t2t3t21t22r211(y)w212(y)r221(y)w222(z)w32(b)r31(z)r11(x)w12(y)tinittfin

  • Observation on Write and Commit OperationsThe 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 tpObservation: Write and Commit operations be implemented atomically, possibly using locks*

  • Read Operation Closest AncestorA 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 heightreads from the buffers of an ancestor closest to itA write operation read by a given read operation is denoted as the reads lastWrite.*

  • lastWrite Specification: Non-nested transactionsIn 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)

    *

  • lastWrite Specification: Nested transactionsIn nested transactions, by reading from the closest ancestor the notion of lastWrite can be definedThe 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 readIs a peer of the read or the peer of an ancestor of the readIs closest in terms of tree heightIs closest in terms of schedule distance We denote this specification of lastWrite as lwSpec

    *

  • Examples of LastWrite using lwSpec

    r11(x) : init(x), r211(y):init(y), r221(y): w21212(y) r31(z):init(z)

    *tRt1t2t3t21t22r211(y)w212(y)r221(y)w222(z)w32(b)r31(z)r11(x)w12(y)tinittfin

  • Limitations of lwSpeclwSpec implicitly assumes that the read operations are atomicSpecifically, it assumes that no other operation is being executed when a read is in progressA read operation that follows closest ancestor option, involves buffers of multiple transactionsHence can not be implemented atomicallyEach read operation is represented as a leaf node in the treeTo correctly capture the read, we assume that the node implies the instant the read completes

    *

  • Limitations of lwSpec: illustrationConsider a nested transaction ti at level 10 (in the tree) wishing to read x, ri(x). Consider this sequenceWhen the control (of the read) reaches a transaction tj at level 9, it does not find any buffer for xThe 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.

    *

  • Non-blocking lastWrite Specification: nblwSpecThe 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 readIs a peer of the read or the peer of an ancestor of the readWe denote this specification of lastWrite as nblwSpecIt 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

    *

  • lastWrite Specification and Conflict notionBased on the specification of the lastWrite, the correctness for the correctness criteria can be definedTwo data operations on the same data-item are conflicting:if one of them is a write operationThen, based on the correctness criteria, accurate conflict notions can be definedUsing accurate conflict notion, efficient algorithms can be devisedSimilar to Conflict Serializability in databases*

  • External ReadsFor a transaction, we defineExternal-read: A read operation belonging to a descendant, whose lastWrite is external to the transactionA simple-memory read is an external read of itself

    *

  • Non-blocking Conflict NotionFor 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 wbw-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, ra and 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)

    *

  • ConclusionCharacterized the non-blocking specification of lastWrites, nblwSpecDeveloped conflict notions based on these non-blocking specification

    *

  • Questions?*

    ****************************

Recommended

View more >