38.17. Designing a Transaction with the Command Pattern
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 worka set of taskswhose 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].Fowler01], the order of database tasks within a transaction can influence its success (and performance).
Fowler02].
For example:
- Suppose the database has a referential integrity constraint such that when a record is updated in TableA that contains a foreign key to a record in TableB, the database requires that the record in TableB already exists.
- Suppose a transaction contains an INSERT task to add the TableB record, and an UPDATE task to update the TableA record. If the UPDATE executes before the INSERT, a referential integrity error is raised.
Command Context/Problem How to handle requests or tasks that need functions such as sorting (prioritizing), queueing, delaying, logging, or undoing?Solution Make each task a class that implements a common interface. |
Figure 38.15. Commands for database operations.
BMRSS96], which can queue, log, prioritize, and execute the commands.