Paper Details

Transactional CSP Processes

Authors: Cassar, Gail, Abela, Patrick

Abstract:

Long-lived transactions (LLTs) are transactions intended to be executed over an extended period of time ranging from seconds to days. Traditional transactions maintain data integrity through ACID properties which ensure that: a transaction will achieve an "all-or-nothing" effect (atomicity); system will be in a legal state before a transaction begins and after it ends (consistency); a transaction is treated independently from any other transactions (isolation); once a transaction commits, its effects are not lost (durability). However, it is impractical and undesirable to maintain full ACID properties throughout the whole duration of a long lived transaction. Transaction models for LLTs, relax the ACID properties by organizing a long-lived transaction as a series of activities. Each activity is a discrete transactional unit of work which releases transactional locks upon its execution. Activities are executed in sequence and can either commit, rollback or suspend execution of the transaction. The long-lived transaction commits if all its activities complete successfully. If any of the activities fail, the long lived transaction should roll back by undoing any work done by already completed activities. Unless an activity requires the result of a previously committed activity, there is no constraint which specifies that the various activities belonging to a long lived transaction execute sequentially. Our proposed research focuses on combining long lived transactions and CSP such that independent activities execute in parallel thus achieving flexibility and better performance for long lived transactions. Very much as the occam CSP-based constructs, SEQ and PAR, allow processes to be executed sequentially or concurrently, the proposed SEQ_LLT and PAR_LLT constructs can be used to specify the sequential or concurrent execution of transactions. Two activities that are coordinated with the SEQ_LLT construct are evaluated in such a way that the second activity is executed only after the first activity commits. This corresponds to the SEQ construct which, from a concurrency perspective, executes in such a way that the second process starts its execution after the first process is complete. Similarly, PAR_LLT specifies that activities can start their execution, independently from whether any other activities have committed their transaction or not. We also use the same synchronization mechanisms provided by CSP to have concurrent activities communicate with one another. An activity which "waits" on a channel for communication with another concurrent activity is automatically suspended (and its transactional locks released) until it receives a message from another activity. A prototype implementation of the described constructs and some example applications have been implemented on SmartPay LLT (a platform loosely based on JSR95 developed by Ixaris Systems). This work has been part of an undergraduate dissertation at the University of Malta.

Proceedings:

Communicating Process Architectures 2007, Alistair A. McEwan, Steve Schneider, Wilson Ifill, Peter H. Welch, 2007, pp 503 - 504 published by IOS Press, Amsterdam

This record in other formats:

Web page: BibTEX, Refer
Plain text: BibTEX, Refer

If you have any comments on this database, including inaccuracies, requests to remove or add information, or suggestions for improvement, the WoTUG web team are happy to hear of them. We will do our best to resolve problems to everyone's satisfaction.

Copyright for the papers presented in this database normally resides with the authors; please contact them directly for more information. Addresses are normally presented in the full paper.