Application Components

Transactions

Transaction Server simplifies the task of developing application components by allowing you to perform work with transactions. This protects applications from anomalies caused by concurrent updates or system failures. Transactions maintain the ACID properties:

• Atomicity ensures that all the updates completed under a specific transaction are committed (and made durable); otherwise , they get rolled back to their previous state.
• Consistency means that a transaction is a correct transformation of the system state, preserving the state constants.
• Isolation protects concurrent transactions from seeing each other's partial and uncommitted results; otherwise they might create inconsistencies in the application state. Resource managers  use transaction-based synchronization protocols to isolate the uncommitted work of active transactions.
• Durability means that committed updates to managed resources (such as a database record) survive communication failures, process failures, and server-system failures. Transactional logging even allows you to recover the durable state after disk media failures.

The intermediate states of a transaction are not visible outside the transaction. If the entire transaction is not completed successfully, the entire transaction fails. This allows you to develop application components as if each transaction executes sequentially and without regard to concurrency.

You can declare a component to be transactional, in which case Transaction Server associates transactions with the component's objects. When an object's method is executed, the services that resource managers and resource dispensers  perform on its behalf execute under a transaction. This also can include work that is performed for other Transaction Server objects. Work from multiple objects can be composed into a single atomic transaction.