db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
@InProceedings{CassarAbela07,
  title =        "{T}ransactional {CSP} {P}rocesses",
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
  author=        "Cassar,  Gail and Abela,  Patrick",
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
  editor=        "McEwan,  Alistair A. and Schneider,  Steve and Ifill,  Wilson and Welch, Peter H.",
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
  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
     \&amp;quot;all-or-nothing\&amp;quot; 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 \&amp;quot;waits\&amp;quot; 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."
}