What's the difference between a transaction coordinator and a transaction manager?

Question

What's the difference between a transaction coordinator and a transaction manager ?

I don't know if this a valid question , but i keep reading these two terms.

If they are different things, What are the products in IBM's Websphere stack that can do these two different jobs?

Answer 1

A Trasaction Coordinator like MSDTC is a server for managing distributed transactions. It holds persistent records of the transactions and manages the communications for the two-phase commit/rollback process with the resource managers. It may or may not be integrated into a transaction manager.

In TP-speak, a 'Transaction Manager' is something that issues commit/rollback requests to 'Resource Managers'. A 'Resource Manager' is something like a database management system that makes a state change transactionally. Two phase commit is a protocol where a transaction manager verifies that all of the resource managers can guarantee to commit a transaction (i.e. have log entries written to persistent storage and no error conditions that would prevent the commit) and then advises the commit. It will then verify that the transaction has been committed by all of the resource managers before marking the transaction as 'committed'.

A Transaction Coordinator is the part of the system that handles this commit process. It may or may not be the same program as the Transaction Monitor. An example of a Transaction Coordinator is MS DTC (Distributed Transaction Coordinator). It is slightly interesting as in this arhitecture (MTS/COM+) it is actually run as a separate process.

A Transaction Manager or TP Monitor is the subsystem that the application uses to control the transaction commit/rollback process. It hosts the middle tier of an application, and provides APIs for getting transaction IDs and voting to commit/rollback the transaction. Where only one process is involved in the vote this is equivalent to advising the commit/rollback. In Java circles this is often known as an 'application server' (or sometimes a 'Bean Container' when using EJB). Examples of Transaction managers are MS Transaction Services (later known as COM+ Transaction Services), CICS and various Java application servers.

Where you have a connection pool and a transaction that spans more than one call to the database, transaction scope must be divorced from session and connection state. Subsequent calls to the DBMS may not be through the same connection. Thus, we need a separate transaction ID that can be used to tag requests to the database. Locks are then owned by the transaction ID.

Because of the dissociation from the database connection, commit and rollback must be controlled out of band from the middle-tier through another protocol. This is the role of the XA protocol (from the XOpen standard) or OLE transactions protocol.

The commit/rollback requests to the resource manager do not have to come from the same server as the one hosting the application. A Transaction Manager can use a separate transaction coordinator to manage the commit/rollback process. These can communicate using a protocol such as TX.(Transaction Demarcation). In other cases the Transaction Manager can issue the commit/rollback instructions to the resource manager (database) directly, using a protocol such as XA. Thus, the transaction coordination and management functions are separate to some extent and may or may not be done by the same piece of software. In the case of MSDTC they are separate, but this is not strictly required.

One advantage of moving the Transaction Coordinator out into a separate process is that it is not so exposed to being crashed by bad application code. In this case, the process only handles the transaction commit hosts no application ocde. Other items communicate with it. This allows the transaction coordinator to be very simple, focussed and resistant to application crashes. Where it is integrated into the application server, an application server crash may take down transactons involving third-party resource managers that are nothing to do with the application. The down side of moving Transaction Coordination into a separate process is increased latency in the transaction commit due to networked requests.

Edit: I'm not sure about Websphere but IIRC the transaction coordinator on Weblogic is called 'Weblogic Transaction Manager' and the transaction management is done through the bean container.