Atomic transactions are the classical transaction type found in most enterprise data systems, such as relational databases.
Atomic transactions typically exhibit ACID properties (Atomic, Consistent, Isolated and Durable).
This is usually achieved by the transactions holding locks on data, particularly during transaction resolution through the two phase commit protocol (2PC).
In J2EE applications, such transactions are normally managed through the JTA interface, or implicitly by the application container in the case of e.g. certain EJB configurations.
Because of their lock based nature, atomic transactions are best suited to short lived operations within the enterprise.
Long lived transactions can exhibit poor concurrency when holding locks for a prolonged period.
For the same reason, use of lock based transactions for inter-enterprise integration is avoided due to the possibility of denial of service situations based on incorrect lock management.
The next section of the trail map explains how these problems can be addressed through the use of an extended transaction model, Business Activities.
To use the Atomic Transaction transaction type in the sample application, simply select it from the pull down menu at the top of the client interface.
Notice that the server applications show the reservation resources (e.g. seats, tables) passing though a lifecycle involving the initial state (free), reserved (locked) and booked (committed).