concurrency control in advanced database applications

ICS 541 - 01 (062) CC in Adv. DB Applications 1

Concurrency Controlin

Advanced Database Applications

Dr. Muhammad Shafique

31 March 2007


Outline

• Advanced computer-based applications• An example• Nested and Multi-level transactions• CC requirements in advanced database applications• Advanced Concurrency control techniques

• Concurrency control requirements in advanced databases• Supporting long transactions

• Altruistic locking• Snapshot validation• Semantic-based concurrency control• Sagas and compensation functions

• Supporting coordination


Reference

“Concurrency Control in Advanced Database Applications”

Naser S. Barghouto, and gail E. Kaiser,

ACM Computing Surveys, Volume 23, number 3, September 1991, pp269-317

NOTE: Please focus on pages 269 to 297 (Sections 1 to 6)


Advanced Computer-based Applications

• Traditional database applications• Banking• Airline reservation systems, etc.

• Advanced database applications• Computer Supported Cooperative Work (CSCW)• Computer-aided design (CAD)• Computer-aided manufacturing (CAM)• Network management• Financial instruments trading• Medical informatics• Office automation• Software development environments


An Example• Software project

• Four modules, A, B, C, and D• Modules A, B, and C consists of procedures and declarations• Module D consists of library procedures called by the other

modules


Nested Transactions • Nested transactions

• A nested transaction is a composition of a set of sub-transactions; each sub-transaction can itself be a nested transaction.

• To other transactions, only top-level nested transaction is visible and appears as a normal atomic transaction.

• Internally sub-transactions are run concurrently and their actions are synchronized by an internal concurrency control mechanisms

• A sub-transaction can fail and can be restarted or replaced by another sub-transaction without causing the whole nested transaction to fail or restart

• An example


Nested Transactions


Multi-level Transactions

• Multi-level transaction classes• Transactions in some systems can be grouped into levels.

Level one groups all transactions in the system whereas the subsequent levels group transactions that are more strongly related to each other

• A strong relation between two transactions might be that they often need to access the same objects at the same time with non-conflicting way.


Advanced Concurrency Control Techniques

• Traditional DBMS enforce serializable executions of transactions wrt read and write operations• No semantic consistency constraints on data

• If enough information is known about the transactions and operations, a non-serializable but consistent schedule can be constructed

• CC requirements in advanced database applications• Supporting long transactions

• Supporting user control

• Supporting synergistic cooperation

• Support for complex objects



• Supporting long transactions• Extending serializability

• Altruistic locking

• Snapshot validation

• Order-preserving serializability for multi-level transactions

• Relaxing serializability• Semantic-based concurrency control

• Sagas

• Conflict predicate correctness

• Dynamic restructuring of transactions



• Altruistic locking• Resources should be locked only for the needed time• Makes use of access pattern of a transaction to decide on which

resources to release• Negative access pattern and positive access pattern• Wake of a transaction --- the set of all data items that have been

locked and then released

• Extended basic 2PL with release option should adhere to two conditions• No two transactions can hold locks on the same data item

simultaneously unless one of them has locked and released the object before the other locks it (Later lock holder is said to be in wake of the former)

• If a transaction is in the wake of another transaction then it must be completely in the wake of that transaction.



• Snapshot validation• Extension of optimistic CC technique

• Serious VS non-serious conflicts

• Solutions to starvation problem• Substitute transaction

• Order-preserving serializability for multi-level transactions• Commutativity of operations



• Relaxing serializability• Semantic-based concurrency control

semantic consistency constraint rather than serializability constraint

• Two transactions are said to be compatible if their operations can be interleaved at certain points without violating semantic consistency

• A transaction is said to be semantically atomic if all its steps are executed or if any executed steps are eventually followed by their counter-steps



• Relaxing serializability• Sagas

• Sagas are LTs that can be broken up into a collection of subtransactions that can be interleaved in any way with other transactions.

• A saga is a collection of unrelated transactions which guarantees that all its sub-transactions will be completed or they will be compensated.

• Compensation functions rather than simple rollback

• A compensation function undoes the actions performed by a transaction from a semantic point of view. For example, reserving a seat and compensating with canceling the seat.

• In SDEs, a transaction to fix a bug can be modeled as a saga that consists of edit a file, compile source code, and run the debugger.



• Supporting coordination• Coordination VS synergistic cooperation

• Pessimistic coordination

• Optimistic coordination

• Synergistic cooperation• Coordination primitives

• Interactive notification

• The group paradigm

• Cooperating transactions

• Transaction groups


Summary

• Concurrency control techniques• Locking techniques

• Timestamp ordering techniques

• Multi-version concurrency control techniques

• Optimistic concurrency control techniques

• Advanced Concurrency control techniques

Thank you

concurrency control in advanced database applications

Documents