1. 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)

2. Introduction Transactions are characterized by the ACID properties: Transactions are characterized by the ACID properties: Atomicity: The effect of the transaction is all or nothing. 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. Isolation: The effect of concurrent transactions should be equivalent to a serial execution of them. Durability: The effect of successful transactions is not lost. Durability: The effect of successful transactions is not lost.

3. Introduction Concurrency control techniques are aimed to support the isolation property. Concurrency control techniques are aimed to support the isolation property. The main technique of concurrency control is locking and more concretely strict 2PL: The main technique of concurrency control is locking and more concretely strict 2PL: Locks are requested when a data item is accessed. Locks are requested when a data item is accessed. Locks are released when the transaction terminates. 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. The granularity of concurrency control has a big impact on the performance of the transactional system. Two different aspects need to be distinguished: Two different aspects need to be distinguished: Concurrency control granularity (the size of the data being locked). Concurrency control granularity (the size of the data being locked). Data granularity (the size of the minimal unit of data accessible from persistent storage). Data granularity (the size of the minimal unit of data accessible from persistent storage).

5. Motivation These two granularities have been traditionally the same. These two granularities have been traditionally the same. This has implied a tradeoff between: This has implied a tradeoff between: The coarser the granularity the more efficient the disk access and the lower the degree of concurrency. 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. 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). 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. 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. 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. 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. Decoupling Data and Concurrency Control Granularity Our approach allows the programmer to set declaratively the concurrency control at inner levels of objects (variables). Our approach allows the programmer to set declaratively the concurrency control at inner levels of objects (variables). 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 array (array_index) ofrecord a : atomic integer; b : atomic float; end record

9. Correctness of Declarative Concurrency Control The atomic keyword cannot be used at any place of the syntax tree of the type. 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: 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. 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. This guarantees that every data item does not lack concurrency control and no item has a duplicated concurrency control.

10. Correctness of Declarative Concurrency Control array record atomic integer float atomic record array atomic integer float array record atomic integer atomic float

11. Implementing Declarative Concurrency Control One option would be to set traditional read/write locks at the needed granularity. One option would be to set traditional read/write locks at the needed granularity. However, this complicates unnecessarily the job of the compiler. However, this complicates unnecessarily the job of the compiler. Another more interesting option is to use semantic locks. Another more interesting option is to use semantic locks. Semantic locks are provided by the underlying transactional run-time system, TransLib/Optima. 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. Semantic locks allow the user to specify the conflict amongst the object operations. For instance, the compatibility relation for a set is: For instance, the compatibility relation for a set is: Insert(y)Remove(y)IsIn(y) Insert(x)Yes x ≠ y Remove(x) Yes IsIn(x) Yes

13. Applying Semantic Locks to User Defined CC Granularity Semantic locks can used in the following way to implement 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. 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. 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. An additional parameter indicates whether the lock is read or write.

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

15. Applying Semantic Locks to User-Defined CC Granularity The semantic locks for the previous example would be: The semantic locks for the previous example would be: FieldA(i,F)FieldA(i,T)FieldB(i,F)FieldB(i,T) FieldA(j,F)Yes i ≠ j YesYes FieldA(j,T) YesYes FieldB(j,F)YesYesYes FieldB(j,T)YesYes F = Read lock T = Write lock

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

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

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

19. Conclusions It has been presented a technique to decouple the concurrency control granularity from the data granularity. 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. 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. Finally, the runtime support for concurrency control has been provided by means of a protected object that guarantees both physical and logical consistency.