A transaction, or business system transaction, is the execution of a unit of work that accesses shared resources and must complete reliably. Completing reliably means that each activity in the unit of work must complete without error or the state of the business system(s) must be returned to a state as if the transaction had not occurred.
For example, if a package of related material items is ingested into a media facility and the ingest of one of the items fails, ingest of all of the items should fail to avoid broken links.
The four characteristics of a transaction that must be met for it to be considered safe are known as ACID, standing for:
- The transaction must either execute completely or not at all.
- The integrity of the underlying data store must be preserved.
- The transaction must be able to execute independently of other processes or transactions.
- The changes made by a transaction must be persisted and not lost on any systems failure.
Implementation of ACID transactions is non-trivial and not all media-related transactions will need to have ACID characteristics. For example, the generation of captions from sports statistics may be best served by showing the latest score rather than a sequence of out-of-date scores that appear as transactions complete. In this example, the transactions are not isolated from one another. The assessment of how ACID a transaction needs to be can be made on a case-by-case basis and is often a trade off between efficiency and the value to a business of maintaining transaction characteristics.
Atomic Transactions vs. Long Running Transactions
Atomic transactions are typically implemented by exclusively locking resources and not committing any modifications of those resources before it becomes clear that the whole transaction can be completed reliably. This approach can work well when all the activities in a transaction can be completed in a short period of time, so that exclusive locking of resources does not degrade the overall level of responsiveness of the system to unacceptable levels.
The assumption of short duration does not hold in the case of so-called long running transactions. These transactions, many of which are found in the media industry, can take hours and sometimes days or weeks to complete, and they are better addressed by a different approach called Compensation. Actions on individual resources are applied immediately and are made permanent, even before knowing that the entire transaction can complete reliably. If during the transaction the initial assumption of reliable completion becomes false, appropriate actions (compensations) are taken to (permanently) reverse the result of actions previously applied to resources, so that the overall consistency of the system can be preserved. SOA business processes typically correspond to long running transactions, and compensation is the most commonly adopted approach to preserve system consistency under those scenarios.
- Wikipedia entry on ACID transactions and databases.
- Bill Burke and Richard Monson-Haefel. Enterprise JavaBeans 3.0. Chapter 16. 5th Edition. O'Reilly. May 2006.