With Network Client starting an XA transaction resets the isolation level set with setTransactionIsolation

• Key: DERBY-414
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Mamta A. Satoor
• Reporter: Kathey Marsden
• Component/s: Network Client
• Affects Version/s: 10.1.1.0, 10.2.1.6
• Fix Version/s: 10.1.2.1, 10.2.1.6

Description

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 if the setTransactionIsolation call comes before the xa transation is started.

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

Comments

[Kathey Marsden]

run repro as
java TestDerbyNSXA

[Kathey Marsden]

If I move the setTransactionIsolation to after the start of the xa transaction the isolation level gets set properly.

It would appear that with embedded if you set the isolation level with
SET CURRENT ISOLATION = UR;
it gets reset on start of the xa transaction to the default.
and that causes this problem with setTransactionIsolation with client.

[Mamta A. Satoor]

The fix went into both 10.2 and 10.1 codeline

reopening to fix fix version