-
1. Re: XA Trouble
davidjencks May 21, 2002 3:30 PM (in response to oravecz)I expect that the locks should be shared for all connections in a tx from one machine at least. Otherwise you might as well tie the transaction to a connection and kill scalability. However, this is not expressed very clearly in the xa docs I have found (such as the jta spec). (i.e. they don't say a word about it). If the connections are from different machines, there is an explicit concept of "loosely coupled" which means that locks won't be shared, and work done from one machine won't be visible to the other.
In any case, I wonder if there is some db or driver setting that will make this work?
Also check that the 2 connections are getting the same xid with the same branchid. -
2. Re: XA Trouble
oravecz May 21, 2002 5:55 PM (in response to oravecz)> I expect that the locks should be shared for all
> connections in a tx from one machine at least.
It turns out that this is not the case. I have a conference call with the Sybase XA engineer tomorrow, but the current support engineer states that an exclusive lock shared by one connection is not shared with another connection even if both connections are controlled by the same XA transaction.
> In any case, I wonder if there is some db or driver
> setting that will make this work?
I can read from the 2nd connection as long as I use isolation level 0, however I can't get that to work in jBoss 2.4.6. It seems that the XAConnectionFactory.prepare method requires my connection to be wrapped in XAConnectionImpl in order for that to work. Not sure how that figures into the configuration options. My SybaseXADataSourceLoader simply exposes a SybXADataSource object. I had to rewrite this because it does not have a setProperties() method that XADataSourceLoader requires.
> Also check that the 2 connections are getting the
> same xid with the same branchid.
The Sybase guys claim that XA simply does not support the sharing of shared locks. Puts a real damper on cascade deletes and validation routines that must validate the state of the database prior to a commit.