1 / 19

Concurrency Control in Transactional Drago

Concurrency Control in Transactional Drago. M. Patiño-Martínez, R. Jiménez-Peris Technical University of Madrid (UPM) J. Kienzle McGill University S. Arévalo Universidad Rey Juan Carlos (URJC). Introduction. Transactions are characterized by the ACID properties:

aden
Download Presentation

Concurrency Control in Transactional Drago

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. Concurrency Control inTransactional Drago M. Patiño-Martínez, R. Jiménez-Peris Technical University of Madrid (UPM) J. Kienzle McGill University S. Arévalo Universidad Rey Juan Carlos (URJC)

  2. Introduction • Transactions are characterized by the ACID properties: • Atomicity: The effect of the transaction is all or nothing. • Isolation: The effect of concurrent transactions should be equivalent to a serial execution of them. • Durability: The effect of successful transactions is not lost.

  3. Introduction • Concurrency control techniques are aimed to support the isolation property. • The main technique of concurrency control is locking and more concretely strict 2PL: • Locks are requested when a data item is accessed. • Locks are released when the transaction terminates.

  4. Motivation • The granularity of concurrency control has a big impact on the performance of the transactional system. • Two different aspects need to be distinguished: • Concurrency control granularity (the size of the data being locked). • Data granularity (the size of the minimal unit of data accessible from persistent storage).

  5. Motivation • These two granularities have been traditionally the same. • This has implied a tradeoff between: • The coarser the granularity the more efficient the disk access and the lower the degree of concurrency. • The finer the granularity the more inefficient the disk access and the higher the degree of concurrency.

  6. Motivation • Our proposal consists in decoupling both kinds of granularities while keeping implicit concurrency control (i.e. programmers do not request explicitly latches nor locks).

  7. Decoupling Data and Concurrency Control Granularity • Traditional systems set data and concurrency control granularities at the object level. • This might be reasonable for the data granularity so programmers can control the size of data being moved from/to persistent storage. • However, some means must be given so they can express a finer concurrency control granularity and increase the efficiency of disk access without trading off the degree of concurrency.

  8. type my_Type is atomic array (array_index) of record a : integer; b : float; end record type my_Type is array (array_index) of atomic record a : integer; b : float; end record type my_Type is array (array_index) of record a : atomic integer; b : atomic float; end record Decoupling Data and Concurrency Control Granularity • Our approach allows the programmer to set declaratively the concurrency control at inner levels of objects (variables).

  9. Correctness of DeclarativeConcurrency Control • The atomic keyword cannot be used at any place of the syntax tree of the type. • The use of the atomic keyword is correct if and only if: • Every branch of the syntax tree of the type contains a single occurrence of the keyword atomic. • This guarantees that every data item does not lack concurrency control and no item has a duplicated concurrency control.

  10. array array array atomic record record record atomic integer atomic integer atomic integer float float atomic float Correctness of DeclarativeConcurrency Control

  11. Implementing DeclarativeConcurrency Control • One option would be to set traditional read/write locks at the needed granularity. • However, this complicates unnecessarily the job of the compiler. • Another more interesting option is to use semantic locks. • Semantic locks are provided by the underlying transactional run-time system, TransLib/Optima.

  12. Semantic Locks • Semantic locks allow the user to specify the conflict amongst the object operations. • For instance, the compatibility relation for a set is:

  13. Applying Semantic Locksto User Defined CC Granularity • Semantic locks can used in the following way to implement user-defined CC granularity: • For each branch in the type tree from the root to nodes tagged atomic, a parameterized lock is generated. • Each of these locks has as many parameters as arrays are found in the corresponding type tree branch. The type of the parameters is the type of the index of the arrays. • An additional parameter indicates whether the lock is read or write.

  14. Each lock has as parameter the index of this array array record atomic integer atomic float A parameterized lock is generated for each branch Applying Semantic Locksto User Defined CC Granularity Plus a boolean para- meter indicating whether the lock is R or W

  15. Applying Semantic Locksto User-Defined CC Granularity • The semantic locks for the previous example would be: F = Read lock T = Write lock

  16. Run-Time Support forSemantic Locking • Semantic locking is implemented using a protected object. • Two levels of concurrency control should be provided: • Long-term to guarantee logical consistency (preserve isolation): locks. • Short-term to guarantee physical consistency: read/write mutex or latches.

  17. Run-Time Support forSemantic Locking • CC prologue and epilogue for each operation: • Prologue: Get lock and then mutex. • Epilogue: Release mutex. • CC epilogue during transaction termination: • Abort: Release locks. • Commit: Propagate/release locks.

  18. Before accessing the object requeue After accessing the object requeue After terminating the transaction requeue Run-Time Support forSemantic Locking Pre_Operation Waiting_Trans Post_Operation Waiting_Writer Trans_Commit Waiting_Readers Trans_Abort Protected object controlling access to a transactional object

  19. Conclusions • It has been presented a technique to decouple the concurrency control granularity from the data granularity. • It has been proposed an implementation based on the use of semantic locking that simplifies the translation. • Finally, the runtime support for concurrency control has been provided by means of a protected object that guarantees both physical and logical consistency.

More Related