Concurrency Control in Transactional Drago

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
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
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

Insert(y) Remove(y) IsIn(y)
Insert(x) Yes x ? y x ? y
Remove(x) x ? y Yes x ? y
IsIn(x) x ? y x ? y Yes
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
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

FieldA(i,F) FieldA(i,T) FieldB(i,F) FieldB(i,T)
FieldA(j,F) Yes i ? j Yes Yes
FieldA(j,T) i ? j i ? j Yes Yes
FieldB(j,F) Yes Yes Yes i ? j
FieldB(j,T) Yes Yes i ? j i ? j
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
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.