Re: [jira] Updated: (DERBY-414) Client XA has a problem with the TRANSACTION_READ_UNCOMMITTED isolation level
Is this problem specific to network client? Kathey Marsden (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-414?page=all ] Kathey Marsden updated DERBY-414: - Attachment: deby414Repro.zip run repro as java TestDerbyNSXA Client XA has a problem with the TRANSACTION_READ_UNCOMMITTED isolation level - Key: DERBY-414 URL: http://issues.apache.org/jira/browse/DERBY-414 Project: Derby Type: Bug Components: Network Client Versions: 10.1.1.0, 10.2.0.0 Reporter: Kathey Marsden Attachments: deby414Repro.zip When using v10.1.1.0 of the Apache Derby Network Client JDBC Driver and configuring the TRANSACTION_READ_UNCOMMITTED isolation level, it is unable to read changes from another transaction which haven't been committed yet. $ java TestDerbyNSXA Connection number: 2. Database product: Apache Derby Database version: 10.2.0.0 alpha Driver name: Apache Derby Network Client JDBC Driver Driver version: 10.2.0.0 alpha Thread 1: transaction started (with read committed isolation) Thread 1: row updated first time. Connection number: 3. Thread 2: transaction started (with read uncommitted isolation) Query complete on thread 2. About to do ResultSet.next()... Thread 1: row updated second time. ResultSet.next() took 19067 milliseconds. Test fails. ResultSet next under read uncommitted isolation appears to have been blocked and unable to perform a dirty read. Thread 1: transaction committed. Thread 2: transaction committed. $
Re: [jira] Updated: (DERBY-414) Client XA has a problem with the TRANSACTION_READ_UNCOMMITTED isolation level
Mike Matrigali wrote: Is this problem specific to network client? Yes. if you switch the repro to use embedded all seems to work ok.
Re: [jira] Updated: (DERBY-414) Client XA has a problem with the TRANSACTION_READ_UNCOMMITTED isolation level
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 Kathey Marsden wrote: Mike Matrigali wrote: Is this problem specific to network client? Yes. if you switch the repro to use embedded all seems to work ok.
Re: [jira] Updated: (DERBY-414) Client XA has a problem with the TRANSACTION_READ_UNCOMMITTED isolation level
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.
Re: [jira] Updated: (DERBY-414) Client XA has a problem with the TRANSACTION_READ_UNCOMMITTED isolation level
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.
[jira] Updated: (DERBY-414) Client XA has a problem with the TRANSACTION_READ_UNCOMMITTED isolation level
[ http://issues.apache.org/jira/browse/DERBY-414?page=all ] Kathey Marsden updated DERBY-414: - Attachment: deby414Repro.zip run repro as java TestDerbyNSXA Client XA has a problem with the TRANSACTION_READ_UNCOMMITTED isolation level - Key: DERBY-414 URL: http://issues.apache.org/jira/browse/DERBY-414 Project: Derby Type: Bug Components: Network Client Versions: 10.1.1.0, 10.2.0.0 Reporter: Kathey Marsden Attachments: deby414Repro.zip When using v10.1.1.0 of the Apache Derby Network Client JDBC Driver and configuring the TRANSACTION_READ_UNCOMMITTED isolation level, it is unable to read changes from another transaction which haven't been committed yet. $ java TestDerbyNSXA Connection number: 2. Database product: Apache Derby Database version: 10.2.0.0 alpha Driver name: Apache Derby Network Client JDBC Driver Driver version: 10.2.0.0 alpha Thread 1: transaction started (with read committed isolation) Thread 1: row updated first time. Connection number: 3. Thread 2: transaction started (with read uncommitted isolation) Query complete on thread 2. About to do ResultSet.next()... Thread 1: row updated second time. ResultSet.next() took 19067 milliseconds. Test fails. ResultSet next under read uncommitted isolation appears to have been blocked and unable to perform a dirty read. Thread 1: transaction committed. Thread 2: transaction committed. $ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
