| Peter Houston provides an excellent comparison of transactional models [Houston 99]. Table 8-4 summarizes the advantages and disadvantages of distributed transactions; Table 8-5 provides the equivalent summary for queued transactions. The major advantages of using distributed transactions are ease of implementing complex transactions and the ability to simplify error detection and correction. The major disadvantages of this model are blocking while waiting for a response, high availability requirements, and potential locking issues. Queued transactions have the advantages of being able to asynchronously process requests , have reduced availability requirements, and have extensibility aspects. The major disadvantages of this model are the difficulties that can be associated with rollback processing/error correction. Some database transactions, particularly when using queued transactions without a TP monitor, can result in operations that cannot be undone or subtransactions that cannot be compensated using a compensating transaction or saga. Therefore, the rollback issues associated with transaction queuing should be a major concern when choosing a model. Table 8-4. Evaluation of Distributed Transactions | Advantages | Disadvantages | | Mature technology Complex transactions possibly easier to implement. Error detection and correction often easier to implement. | Subject to locking conflicts that can be difficult to solve Tight coupling between requester and server Requires high availability, so all parts of the system ”applications, middleware, network, and platforms ”must be available Requester is blocked while waiting for a response | Table 8-5. Evaluation of Queued Transactions | Advantages | Disadvantages | | Less subject to locking conflicts Less dependent on network and application availability Usually easier to extend than distributed transactions (less coupling) Requester is not blocked while waiting for a response Allows for more parallel processing to occur Possible to remove request from the queue and process based on priority Possible for the requester to determine the state of the request | States can arise whereby requester is unsure of the fate of its messages May be more difficult to implement complex transactions, such as Error detection and correction Rollback processing | Because both models have their own strengths and weaknesses, the choice depends on the context of the system being built. As a result, it is impossible to definitively state which model is best. However, some general guidance can be provided. -
The choice of a model goes hand-in-hand with the choice of the technology that implements it. Therefore, a major criterion in choosing a model is the availability of an implementation and its qualities, such as reliability, usability, and maintainability. -
If the client that starts a transaction must wait for a response from the server before proceeding, the distributed-transactions model is the better choice because distributed transactions can often be easier to implement than queued transactions. However, if a client starts a transaction, does not need to wait for a response, and can do other processing in the meantime, queued transactions may be a better choice [Chappell 98]. -
If some server applications may not always be available, network availability may be intermittent, or network performance slow, consider using queued transactions [Chappell 98]. -
If more than one server can handle a transaction, consider queued transactions. Load balancing can be implemented easily with queued transactions. A set of servers could be configured to read requests from a single transactional queue. It is important to note that some TP monitors and EJB servers automatically provide load balancing that is usually based on a simple round- robin model. With queued transactions, it is easier to implement more sophisticated and effective load-balancing techniques, such as the ability to prioritize transaction requests. -
If issues concerning rollbacks cannot be solved using compensating transactions, a saga, or a change to the business logic, seriously consider using distributed transactions. |
