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.
> 
> 
> 
> 
> 
> 
> 

Reply via email to