Cooperative Transaction Model

1. Cooperative Transaction Model Cooperative database system: A constructive review of Cooperative Transaction Models Anita Gupta Review of Heri Ramapiaro and Mads Nygårds’ paper September 29, 2004

2. Introduction • Reliability is crucial for the cooperative information system • The definition and use of correctness criteria • Support for consistent handling of failures and exceptions • These issues have been widely addressed in traditional database systems through the adoption of the concept of transaction • Transaction Support • Transaction Action or series of actions, carried out by user or application, which accesses or changes contents of database. • Solve problems incurred by concurrent access to shared objects

3. Cooperative work characteristics • Definition of cooperative work: • “a work process involving several people acting together, in a shared context to perform some tasks in order to achieve a pre-specified common goal” • Cooperative work characteristics • The degree of cooperative • Variable number of users • Separation(time and space) • Variable length of interaction • Dynamic interaction

4. “Standard” advanced transaction models • Four basic (ACID) properties of a transaction • Atomicity “all or nothing” property • Consistency transform database from one consistent state to another consistent state • Isolation intermediate states are invisible • Durability committed results are permanent • ACID are too restrictive and too simple for advanced and cooperative applications

5. “Standard” advanced transaction models • Nested Transaction model (by Moss) • Extend the flat transaction by splitting transactions hierarchically into several recursive sub-transactions • Constraints on the sequences of parent transaction and child transaction, e.g. • child transaction may start after its parent has start • parent transaction may terminate only when all of its children have terminated • if parent transaction aborts, all of its children must rollback independent of their current state • Full local and global isolation are required • Modularity, more concurrency and finer recovery granularity

6. “Standard” advanced transaction models • Saga (by Garcia-Molina and Salem) • Deal with long transactions • Sub-transaction is allowed to commit individually • Compensating transaction undo its effect if the whole Saga transaction has to abort • Relax the full isolation requirement • Drawback: not fully implemented

7. “Standard” advanced transaction models • Cooperative Transaction Hierarchy (by Nodine and Zdonik) • A tree based approach root: transaction groups (TG) leaf: cooperative transactions (CT) • CT don’t need to be serializable, TG need correctness criteria: patterns: a set of rules for how operations can be interleaved conflicts: a set of rules that specify which operations are not allowed to run concurrently • Weakness: need to define both patterns and conflicts in advance

8. “Standard” advanced transaction models • Open nested transaction and its specialization multilevel transaction models (by Weikum and Schek) • Improve the nested transaction model by allowing sub-transactions to issue final commit and by using compensation. • Tree based approach but for multilevel model • Compromised atomicity property sub-transactions don’t need to run successfully for the transaction to terminate • Relaxed global isolation reveal partial results to other concurrent transaction • Drawback: stick to serializability as their correctness criterion; implementation of the model is limited

9. “Standard” advanced transaction models • Split/Join Transaction (by Keiser and Wu) • Dynamic reconstruction of running transactions split a running transaction into two or more transactions and later join other transaction by merging their resources • An adaptive recovery mechanism • Part relaxed isolation • Drawback: complex merging mechanism; two resulting transactions from the split command are still isolated to obey a serializability criterion

10. “Standard” advanced transaction models • ACTA • Not a transaction model but a framework to specify transaction models • First-order logic is used to capture properties of transactions (such as visibility, consistency, recovery, permanence) • ACTA-axioms: Its main building blocks are history, inter-transaction dependencies, transaction view, conflict set, delegation. • Drawback: implementation of ACTA-models are not always straight-forward

11. Towards cooperative transaction models • Two categories of effort on cooperative transaction models • Developments based on cooperative work requirements, focusing on the CSCW perspective • Developments based on extensions of existing database fundamentals( e.g. locking protocols and timestamp ordering)

12. Towards cooperative transaction models • Coo • Based on the software development process requirements • Relaxed atomicity and relaxed isolation • Intermediate results are managed by applying three different object consistency levels: • stable objects • semi-stable objects • unstable objects • Date exchanges operations • check in • check out • upward commit • refresh Public Stable Object Semi-public Semi-Stable Object Private Unstable Object Object Consistency/state Database/Workspace

13. Towards cooperative transaction models • Collaborative databases • Main goal: to develop a transaction model by merging flexible transaction models from collaborative environments and semantic based correctness criteria. • Relative atomicity of co-actions (a sequence of read and write operations executed on data objects ) • Collaboration channel • Relative serializability (RSR) • Extension of the standard 2-phase lock protocol (2PL) • push-forward lock • push-backward lock

14. Towards cooperative transaction models • EPOS transaction model • Expert System for Program and (“Og” in Norwegian) System Development Software Engineering Environment focusing on Process Modeling based on Object-Oriented principles • EPOSDB: a client-sever database handling version control • Based on the use of workspaces ( private and common) • Checkin/checkout operation • Two types of lock: mandatory and cooperative locks • Awareness support • Conflict change detection mechanism • With ability to define a set of operations before the transactions are run

15. Towards cooperative transaction models • TransCoop/CoAct • Goal: to develop a transaction model and a specification language to enable effective information sharing • CoAct is the transaction model • Ideas shared with “standard” advanced transaction models: compensation, semantic-base concurrency control,resource exchange,delegation • Exchange of operations instead of exchange of data • Validate history

16. Towards cooperative transaction models • New Timestamp ordering approach • Allow short transactions and long transactions to be run within the same system • Transactions ordered globally so that older transactions, transactions with smaller timestamps, get priority in the event of conflict. • Conflict is resolved by rolling back and restarting transaction • No locks so no deadlock • Can be generated by using system clock at time transaction started, or by incrementing a logical counter every time a new transaction starts

17. Transactional support requirements • Transactional support requirements: a set of requirements transaction models must satisfy in order to support cooperative work. • Transaction properties R1: Compromised atomicity R2: Sharing of intermediate results • Transactional support R3: Open-ended running R4: Scalability R5: Distribution and heterogeneity • Services provided R6: Awareness R7: Temporal data management R8: Access control