A Trasaction coordinator, such as MSDTC, is a server for managing distributed transactions. It contains persistent transaction records and message management for a two-phase commit / rollback process with resource managers. It may or may not be integrated into the transaction manager.
In TP-talk, “ Transaction Manager” is what causes commit / rollback requests for “Resource Managers”. A “resource manager” is a kind of database management system that makes a state transaction a transaction. Two-phase commit is a protocol in which the transaction manager verifies that all resource managers can guarantee the transaction (i.e. have log entries written to the persistent store and no error conditions that could prevent the commit), and then advises the commit. He then verifies that the transaction has been completed by all resource managers before marking the transaction as “committed”.
The transaction coordinator is part of the system that processes this commit process. This may or may not be the same program as the Transaction Monitor. An example of a transaction coordinator is MS DTC (Distributed Transaction Coordinator). This is a little interesting, as in this architecture ( MTS / COM + ), it actually starts as a separate process.
A transaction manager or TP monitor is a subsystem that an application uses to manage the transaction / rollback commit process. It hosts the middle tier of the application and provides an API for retrieving transaction identifiers and voting to commit the transaction. If only one process participates in the vote, this is equivalent to consultation on fixation / rollback. In Java circles, this is often referred to as the “application server” (or sometimes the “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.
If you have a connection pool and a transaction that spans more than one call in the database, the transaction scope should be separate from the session and connection status. Subsequent calls to the DBMS may not be through the same connection. Thus, we need a separate transaction identifier that can be used for database query tags. Then the locks belong to the transaction ID.
Due to the dissociation of the database connection, commit and rollback must be controlled out of range from the middle layer through another protocol. This role is the XA protocol (XOpen standard) or the OLE transaction protocol.
Commit / rollback requests to the resource manager should not come from the same server on which the application is hosted. The transaction manager can use a separate transaction coordinator to manage the commit / rollback process. They can communicate using a protocol such as TX. . In other cases, the transaction manager can directly pass commit / rollback instructions to the resource manager (database) using a protocol such as XA. Thus, the functions of coordination and transaction management are to some extent divided and may or may not be performed by the same software. In the case of MSDTC, they are separate, but this is not strictly required.
One of the advantages of moving the Transaction Coordinator to a separate process is that it is not criticized by bad application code. In this case, the process only processes transaction hosts that do not contain ocde applications. Other items communicate with him. This allows the transaction coordinator to be very simple, focused and resistant to application crashes. When it is integrated into the application server, when the application server fails, a transaction may change with the participation of third-party resource managers who have nothing to do with the application. The downside of moving transaction coordination into a separate process is an increase in transaction latency due to network requests.
Edit: I'm not sure about Websphere, but the IIRC transaction coordinator in Weblogic is called "Weblogic Transaction Manager", and transaction management is done through a bean container.