![]() |
![]() | ![]() | ![]() | |
| Advanced Enterprise Middleware | |||
|
|
Long Running Unit of Work (LRUOW)The Long Running Unit of Work (LRUOW) project addresses the reliability concerns of business processes that execute over extended periods of time. IntroductionToday's advanced applications are placing new transactional requirements on middleware systems. In particular, existing middleware transaction services fail to support the long-running transactions often found in enterprise applications. The Long Running Unit of Work (LRUOW) project attempts to address this by introducing a model designed specifically to support applications where transactions are long-lived and concurrently executing.BackgroundThe lock-based approach typically employed by traditional transaction models is practical only when transactions are short-lived, as transactions are otherwise forced to wait unacceptably long periods of time. Furthermore, these models typically support flat-transactions only, which limits modularity and recoverability; software reuse and modularity, an attractive dividend of modern development methodologies, are often crippled when flat-transactions are introduced. These observations are not, of course, new; alternative approaches have been proposed to address these problems. Optimistic concurrency control is an alternative to locking. Rather than locking objects, each transaction proceeds with its own copy of these objects in the hope that no conflicts will exist upon transaction completion. Although this approach can lead to greater concurrency, transaction throughput degrades when conflicts do occur and transactions must be redone. More fundamentally (for long running transactions) redoing work that has been performed over long periods of time (on the optimistic assumption that the work will succeed) is unacceptable for many applications. Sagas were specifically introduced to deal with long running transactions. In this model, a long-running transactions is decomposed into a chain of short-lived transactions: either the entire chain executes or a series of compensating transactions undo its effects. The saga model does not, however, address isolation (because the component transactions have committed so that their results are visible to other transaction). Also, the Sagas model requires application-specific semantic compensations for each of the short-lived transactions: this approach runs counter to the expectation that transactional technology removes the need for application-specific logic for commit and abort actions. Nested transaction models do address the issue of modular transaction programs, and offer finer grained transaction recovery. However, because these models require locking, they are appropriate only for short-lived transactions. The LRUOW ApproachThe LRUOW model employs a non-strict optimistic approach, where transaction compatibility is considered instead of a binary decision regarding transactional conflicts. This allows concurrently executing transactions to manipulate a common set of resources, yet not automatically force transactions to rollback. Rather, a commit protocol attempts to reconcile conflicts when they occur. The LRUOW model also supports transaction nesting, allowing finer grained failure/recovery control and improved transaction modularity. PeopleThe LRUOW project is a joint effort by Brian Bennett, Thomas Mikalsen and Isabelle Rouvellou, of the Advanced Enterprise Middleware group (IBM T.J. Watson Research Center), Avraham Leff and Jim Rayfield of the Intelligent Object Technology group (IBM T.J. Watson Research Center) in collaboration with Randy Cox, Shawn Everly, Bill Hahm, and Kevin Rasmus, from Country Companies Insurance. MoreAdditional information on the LRUOW model can be found in the paper A Distributed Object Oriented Framework to Offer Transactional Support for Long Running Business Processes . Questions and/or comments about this project can be directed to Thomas A. Mikalsen: tommi@us.ibm.com.
|
| About IBM | Privacy | Legal | Contact |