Transactions in Distributed Environments

Transactions are important to create atomicity for a set of otherwise distinct actions. The classic example is the electronic bank wire, in which the debit to the source account and the credit to the receiving account must either both take place or neither. Client/server RDBMS has helped make transactions accessible to more applications, and now even desktop databases such as Access and Visual FoxPro support transaction semantics.

2-Tier Implementations

Using transactions in typical 2-tier applications, where there is a single connection to a single RDBMS, is almost trivial. All transaction processing takes place in the engine process(es), which also handles the separation of transactions from separate client connections. The client simply bounds the transaction with BEGIN TRAN, COMMIT TRAN and ROLLBACK TRAN statements. This becomes more complex if the client applications wants to coordinate transactions across two or more RDBMS engines, or between an engine and other local events such as renaming a file on a LAN server or sending an e-mail notification. The client application requires code to execute this coordination. In order to do a truly thorough job, it must implement a logging architecture similar to an RDBMS to ensure all required actions are performed in the event the application crashes. Despite the complexity, the fact that a single client process initiates and coordinates the various activities that are part of the transaction usually means the implementation is feasible.

3-Tier Implemenations

With three or more tiers, the feasibility of coordinating an arbitrary set of actions as a single transaction is not guaranteed, regardless of the amount of design and programming thrown at the problem. The primary issue is that actions are initiated by multiple processes, the coupling of which may range from very strong (as in certain RPC implementations) to very weak (as for most message queues). The lower the coupling, the more difficult it is to include actions from the processes in a single transaction. Further, each process uses its own resources, such as server connections, and has its own life cycle. (The latter can result in the situation in which a process needed to participate in a rollback is already dead.) An individual process may be unable to (due to technical restrictions of its implementation) or choose not to directly support transaction semantics.

At the very least, transaction processing requires processes be coupled with a send/reply protocol. Thus, RPCs and other mechanisms with RPC characteristics, such as DCOM, SOM and CORBA, provide some foundation for transactions. On the other hand, message queuing is usually not an appropriate IPC mechanism for transactions, as there may be no reply, or the timeliness of a reply might not be guaranteed. Indeed, these characteristics are generally strengths of message queuing.

RPC Server Models

Among RPC implementations, the server model determines how well services based on this mechanism will participate in hand-coded transactions. A process-per-request model cannot handle transactions across multiple requests; a thread-per-request model might be similarly limited, depending on how the RDBMS connection resource is shared. A process- or thread-per-connection model supports transactions, assuming the client can (and does) make all requests within the context of a single connection. Process and thread pools can cause difficulties, depending on the model used to route requests and whether each process or thread distinguishes which client is making the request. Blocking and mulitplexing models similarly depend on whether the server maintains separate resources for separate clients across multiple requests.

Distributed Transaction Infrastructure

Even if the server model can support transactions, the amount of code that must be designed and implemented on the client is quite large, and its complexity is beyond the capabilities of some development staffs. This ultimately leads to the recommendation to only implement distributed transactions based on commercial software infrastructures. The most obvious and most mature such infrastructure is provided by transaction processing monitors such as Tuxedo, Top End and CICS. These were designed explicitly for distributed transaction processing. Besides standard RDBMS engines, TP monitors can also coordinate transations across controllers that comply with the X/Open XA standard. Transaction support is also being defined for DCOM and CORBA, which will give these technologies a huge advantage over vanilla RPCs and direct socket I/O. Whether the transaction technology built into these mechanisms is XA compliant remains to be seen.

For more information on server models and distributed transaction middleware, see 3-Tier for Improved Database Throughput.