First Name : Mark

Last Name : Little

Title : Dr

Company : Computing Science Department

Address : Claremont Tower, Newcastle University

City : Newcastle upon Tyne

State : Tyne and Wear

Mail Code : Telephone : +44 191 2228066

FAX : +44 191 2228232

E-mail : M.C.Little@ncl.ac.uk

Cyberpaper : Object decomposition in transactional applications The structuring mechanisms available within transaction systems are sequential and concurrent composition of (sub-) transactions. These are sufficient if an application function can be represented as a single top-level transaction. Frequently this is not the case. Top-level transactions are most suitably viewed as "short-lived" entities; they are less well suited for structuring "long-lived" application functions (e.g., running for days). Long-lived top-level transactions may reduce the concurrency in the system by holding on to locks for a long time; further, if such a transaction aborts, work already performed could be undone.

The OMG has recently begun to standardize real-time transaction extensions to improve application performance. They intend doing this through the provision of relaxed ACID semantics, allowing locks to be released before the transaction terminates. However, little attention has been paid to which applications have a need for such functionality and why. The applications cited tend to be "monolithic", with coarse locking granularity, such that locking one item prevents users from inspecting/modifying other, non-conflicting items. We contend that object-orientation, and application decomposition into objects, offers one solution to some of the problems identified by the OMG. The object is the natural unit of concurrency and persistence, and objects can contain other objects. Therefore, the amount of resource contention can be reduced by restructuring an application into objects, with the benefit that no changes to the transaction model are required. Unfortunately tools to assist programmers in this area are lacking.

However, for certain applications object decomposition may not provide the entire solution, and some ACID relaxation may be necessary; importantly the required functionality may be achieved through higher-level APIs, e.g., nested top-level transactions. We believe that the types of performance improvements currently required are achievable through a combination of object decomposition and these extended transaction APIs.