Something that is different for XA is that each transaction tends to get a lot more context rebuilt then for normal connection (this is because other threads can "pick up" and enter a global transaction). I wonder if the isolation gets set ok the first time, but then gets lost?
Kathey Marsden wrote: > Mike Matrigali wrote: > > >>ok, then it seems like somehow the network client is not setting the >>right isolation level - rather than isolation level stuff in the server >>not working. >> >>I am not sure what it takes to get tests running against network server >>but the following tests in the embedded server test out a lot of >>different specific locking cases against all 4 isolation levels. They >>are ij tests, so may not be exercising the same path as your test case >>is using to set the isolation level: >>store/readlocks.sql >>store/updatelocks.sql >> >> > > To run tests for client you just specify -Dframework=DerbyNetClient > > Client sends a SET CURRENT ISOLATION statement with setTransactionIsolation > and that all seems to be working ok for regular connections and is > tested with jdbcapi/setTransactionIsolation.java > > Running the repro with derby.drda.debug=true in the derby.properties > file, you can see that the SET CURRENT ISOLATION statement flows for > the xa connection too in the test case but somethhing is going wrong > somewhere, but this seems to be xa specific. I haven't looked closely > at it though. > > > > > > >
