July 2001
Intermediate to advanced
656 pages
15h 51m
English
The last section took a simplified view of transactions. This section extends the discussion, but does not cover all transaction design issues. Informally, a transaction is a unit of work—a set of tasks—whose tasks must all complete successfully, or none must be completed. That is, its completion is atomic.
In terms of the persistence service, the tasks of a transaction include inserting, updating, and deleting objects. One transaction could contain two inserts, one update, and three deletes, for example. To represent this, a Transaction class is added [Ambler00b].[10] As pointed out in [Fowler01], the order of database tasks within a transaction can influence its success (and performance). ...
Read now
Unlock full access