1 / 14

Position Graph: A New Mechanism for Concurrency Control

Position Graph: A New Mechanism for Concurrency Control. S.N. Maheshwari Work done in collaboration with R.P. Rustagi. Position Graph. Graph in which nodes represent transactions Nodes located on a line starting from 0 and extending indefinitely

lave
Download Presentation

Position Graph: A New Mechanism for Concurrency Control

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. Position Graph: A New Mechanism for Concurrency Control S.N. Maheshwari Work done in collaboration with R.P. Rustagi

  2. Position Graph • Graph in which nodes represent transactions • Nodes located on a line starting from 0 and extending indefinitely • pos(Ti) is the position on the line at which the transaction Ti is located • pos(Ti) < pos(Tj) indicates that Tj follows Ti in the “serial” order of execution

  3. T1 T2 T3 T4 T5 T6 A read step ri(x) of transaction Ti results in insertion of edge Tj –> Ti if Tj = TWL(x) A write step wi(x) of transaction Tiresults in insertion of edge Tj –> Ti and Tk –> Ti if Tj RL(x) and Tk = TWL(x)

  4. Two position graphs PGi = (Vi, Ei) and PGj = (Vj, Ej) are said to be equivalent if • There exists a one to one onto mapping f : Vi -> Vj and • For any two nodes u, v Vi , such that pos(Tu ) < pos(Tv ) and there exists a path from u to v, then pos(Tf(u) ) < pos(Tf(v) ) and there exists a path from f(u) to f(v)

  5. Scheduling of transaction steps using position graphs is done by attempting to maintain all edges as forward edgesA back edge Tj -> Ti has to be converted into a forward edge • This is possible as as long as there is no path from Ti to Tj. This involves • Forward Movement • Backward Movement

  6. Scheduling Read and Write Steps • Read Step • Involves insertion of only one edge in the position graph as a read step conflicts only with the last write step • Write step • A write step conflicts with the last write step as well as all subsequent read steps after the last write step. Involves insertion of r + 1 edges

  7. It can be shown that amortised cost of scheduling • Read Step • 2 edge insertion • Write Step • 1 edge insertion

  8. Timestamp Ordering • Position graph based scheduler permits no node movement at all • Need to maintain only max(RL(x)) representing the transaction with the highest time stamp which has read the entity x • Position value of transaction WL(x) corresponds to the write timestamp

  9. Two Phase Locking • An edge Tj Ti corresponding to conflict on entity x represents that • Tj has released a lock on x, and • Ti has acquired a lock on x • Since a transaction can not acquire a lock after it has released a lock we have • An new edge can be incident at a node provided no edge has emanated from it

  10. Descendent Free Node Movement (DFNM) ProtocolRESTRICT NODE MOVEMENT IN A POSITION GRAPH TO FORWARD MOVEMENT OF DESCENDENT FREE NODES • DFNM protocol • Accepts all 2PL and Timestamp Schedules • Is deadlock free • Is Order Preserving

  11. Implementation Issues • Only need to maintain a boolean variable to keep track of whether descendents exist. No adjacency lists • To prune the position graph and the associated structures transactions are characterised as live and active • Active if a transaction has not completed • Live if active or there is an ative transaction with smaller position value

  12. Implementation continued • Maintain a live transactions table and live data entity table • With each transaction in the live transaction table maintain a list of data items written and read by it • For each live data entity x maintain WL(x) and readlist(x) • x is removed from the table if it is not being accessed by a live transaction

  13. Implementation compared with 2PL • In 2PL one has to maintain • An active transaction table • locks and wait-queues with each data item in lock table • Maintaining the live transaction table is equivalent to maintaining active transaction able and issue of lock and unlock actions in 2PL • WL(x) corresponds to exclusive lock on x, and readlists corresponds to shared locks

  14. CSR Extended DFNM-k DFNM TS OPCSR 2PL

More Related