Prompted by several adapters and jms systems that
provide (what I regard as) only partial xa support,
I've refactored the ConnectionManagers for jboss 3.2
and 4 to support additional capabilites. These may
often be useful and result in faster speeds with
completely compliant adapters also.
The new capability is to have a xa connection manager
keep a ManagedConnection/XAResource associated with a
transaction from the time it first knows about the tx
to commit/rollback.
Advantages: repeated end(suspend) start(resume) call
pairs are avoided, presumably reducing traffic to the
EIS and speeding up your work. This also allows the
use of adapters that require all work in a transaction
to go over the same connection, or that do not allow
end(xid1) start(xid2) calls on the same ManagedConnection.
Disadvantages: This can result in the same kind of
resource starvation/deadlock as local tx adapters are
susceptible to. If your typical unit of work involves
a transaction in which a "requires new" operation is
executed, it is entirely possible for all connections
to be used in the outer transaction thus leaving none
available for the "requires new" operation. In some
circumstances it may result in much less efficient use
of connections, for instance if a transaction does work
on EIS A, then lengthy work on EIS B, then more work
on EIS A. If connections to EIS A are released through
end(suspend) calls, they may do work in other
transactions while the work on EIS B completes. Using
the new capability, they will be unavailable until the
entire transaction completes.
How to use: set matchConnectionToTransaction true in
the XATxConnectionManager configuration.
Note that both LocalTxConnectionManager and
XATxConnectionmanager are now legacy wrappers solely
for backward compatibility. All functionality is in
the new TxConnectionManager, which may be set up to use
local or xa tx, and to match or not match connections
to tx. I anticipate changing the xslt script soon to
use just the TxConnectionManager with the appropriate
flags.
Change in 3.2 functionality:
In order to work around limitations of a jms
implementation, the xa delist operation resulting from
a connection handle close was previously changed to use
end(success) in branch 3.2. It has been changed back
to the more spec compliant end(suspend). Adapters that
cannot accept this call should tie the connection to
the tx so suspend/resume will never be called.
Logged In: YES
user_id=9459
In 3.2
Changed JmsXA in jms-service.xml to use
<attribute name="TrackConnectionByTx">true</attribute>
since JBossMQ requires it.
Regards,
Adrian