WoTUG - The place for concurrent processes

Paper Details

@InProceedings{CassarAbela07,
  title = "{T}ransactional {CSP} {P}rocesses",
  author= "Cassar, Gail and Abela, Patrick",
  editor= "McEwan, Alistair A. and Schneider, Steve and Ifill, Wilson and Welch, Peter H.",
  pages = "503--504",
  booktitle= "{C}ommunicating {P}rocess {A}rchitectures 2007",
  isbn= "978-1-58603-767-3",
  year= "2007",
  month= "jul",
  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."
}

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.

Pages © WoTUG, or the indicated author. All Rights Reserved.
Comments on these web pages should be addressed to: www at wotug.org

Valid HTML 4.01!