In order to understand distributed transactions in XA let us consider the following example.
Assume a bank with
two branches B1 and B2, each having its own database server DBS1 &
DBS2.
Assume branch B1 has
an account A1 & branch B2 has an account A2.
Assume account A1
has balance USD 100 & account A2 has balance 0.
Assume a transfer of
USD 100 is initiated from account A1 to A2.
The following
diagram shows how would this get accomplished using transaction
manager.
The problem with the
above sequence of steps when tried with PostgreSQL as a database
server (resource manager as its called in XA) is as follows:
In step 2, the
transaction manager (TM) starts a transaction on DBS 1 by sending BEGIN
TRANSACTION on a connection that it has established with the server
using any of the available connectors.
In step 4, the
client has to send the UPDATE statement to the server on the same
connection that was used by the transaction manager, for it to be
part of the transaction started by the TM. This is not possible
because PostgreSQL does not support transferring a transaction from
one connection to another.
This problem can be
solved, if some how the transaction manager and the transfer
application could share the same connection. This can be accomplished
by putting a connection pooling system in front of the database
server. The connection pooling system has to support connection
sharing between applications based on some parameter provided by
applications at the time of connection e.g application_name.
If two applications
provide the same application_name while connecting to the pooler, the
pooler will provide them the same connection.
This is exactly the
same technique we used at EnterpriseDB to make PostgreSQL work as a
resource manager with Tuxedo. However there are some application
servers that have built in poolers and support the connection sharing
feature by default. Jboss is one example and the parameter that
controls this feature is “track-connection-by-tx” described here:
No comments:
Post a Comment