Paper Details

%T Transactional CSP Processes
%A Gail Cassar, Patrick Abela
%E Alistair A. McEwan, Steve Schneider, Wilson Ifill, Peter H. Welch
%B Communicating Process Architectures 2007
%X 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.

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.