connection sharing for XA mode in Connector

[mark_dixon]

Does JBoss support connection sharing for XA type
JCA resources ?

[davidjencks]

I believe the XA ConnectionManager only lets out one Connection handle to a ManagedConnection at a time. Is there some reason you would expect otherwise? I am curious, I do not entirely understand the connection sharing stuff. My impression at the moment is that it is mostly to support LocalTransaction adapters and applications where Connection handles are cached over transaction boundaries; at the moment jboss does not support keeping a connection handle open over a transaction boundary. Any info you have would be appreciated.

[slaurent]

I've just been seing this behavior of jbosscx where only one connection handle per managed connection is issued. Actually, my feeling is that all the connection sharing system illustrated in section 6.10.3 of the JCA spec can be applied for XA transactions. Why not ?
Because if you don't do it, you can potentially reduce performances because multiple physical connections will be made to the same EIS for a single transaction. Unless the RA developer uses its own connection sharing, meaning that ManagedConnection are not physical connections yet but rather handles to a real physical connection... That would completely drop the benefits of the JCA spec, don't you think ?

(perhaps we should continue this interesting discussion on the JCA mailing list no ?)

[davidjencks]

In a properly designed ra, using a different managed connection for each chunk of work in an xa transaction has no adverse effect on performance. Basically you are just including the xid in each communication with the resource manager, which you have to do anyway. All the connections here are in the pool anyway (after startup), the cm just picks a random free connection, gets it in the right transaction, makes a handle and hands it out.

I still think the only reason for connection handle sharing is to support caching connection handles over transaction boundaries without tying up the managed connections, and to make local transaction connectors work.

[mark_dixon]

> In a properly designed ra, using a different managed
> connection for each chunk of work in an xa
> transaction has no adverse effect on performance.

Hi ,
you are right that if each chunk of work is done in
a XA mode, then it does not matter which connection
handle is used. However, considering most of the XA
resources that exist today, multiple connections
do not share resources(locks) even though they are
participating in the same global transaction. The
XA specification terms this behaviorr as loosely-
coupled resource. Hence, connection sharing for
XA results in same performance benefits as that
for local transactions.

-Mark

[davidjencks]

This is interesting news. I haven't looked at the specs lately, but I had thought that loosely coupled only applied when the resource manager got several different xids all belonging to the same global transaction. I thought the resource manager was supposed to treat all work on the _same_ xid tightly coupled.

If you are right, this will tend to kill scalability for such resource adapters. You will be tying up one connection for the entire length of each transaction, rather than freeing it between chunks of work.

Are you sure? I've had a lot of trouble finding references about this stuff -- any documentation would be very welcome.

[mark_dixon]

> This is interesting news. I haven't looked at the
> specs lately, but I had thought that loosely coupled
> only applied when the resource manager got several
> different xids all belonging to the same global
> transaction.

That is right, loosely coupled only applies to
different branches in the same global transaction.
The behavior that I have seen in XA mode is that,
each getConnection call creates a new transaction
branch if the appserver does not support connection-
sharing.
Now suppose I have a BMP calling another local BMP in
the same CMT (XA mode) and methods in both the beans
invoke getConnection on the same RA. Then I have seen
that the appserver creates new transaction branch
for the second getConnection call. This results in
two connection handles with different branch ids
participating in the same global transaction, and
thereby the problems in loose coupling.

Mark

>I thought the resource manager was
> supposed to treat all work on the _same_ xid tightly
> coupled.
>
> If you are right, this will tend to kill scalability
> for such resource adapters. You will be tying up one
> connection for the entire length of each transaction,
> rather than freeing it between chunks of work.
>
> Are you sure? I've had a lot of trouble finding
> references about this stuff -- any documentation
> would be very welcome.

[davidjencks]

Hmmm... Is this happening right now with jboss? Is the XAResource.isSameRM() implemented so it returns true for the 2 MC's involved? If yes... looks like a bug to me. Or does the jta or xa spec prohibit 2 concurrent connections with the same xid?

So you are saying one way to fix this is to keep track of checked-out mc's (ones with open connection handles) via their current xid's and if another request comes in on the same xid get another handle to the same mc?