TxDecisionMaker has been modified for READ_UNCOMMITTED Isolation Level

[fusunc]

When Isolation level is READ_UNCOMMITTED if the transaction is not committed yet another transaction should not wait .

[katzyn]

Hello!

I think your changes are incorrect.

Try this:

Connection conn1 = DriverManager.getConnection("jdbc:h2:mem:test");
Statement stat1 = conn1.createStatement();
stat1.execute("CREATE TABLE TEST(ID BIGINT PRIMARY KEY, V INT)");
stat1.executeUpdate("INSERT INTO TEST VALUES (1, 10), (2, 20)");
conn1.setAutoCommit(false);
Connection conn2 = DriverManager.getConnection("jdbc:h2:mem:test");
conn2.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);
conn2.setAutoCommit(false);
Statement stat2 = conn2.createStatement();
ResultSet rs = stat1.executeQuery("SELECT * FROM TEST FOR UPDATE");
int r = 0;
while (rs.next()) {
    r++;
}
System.out.println("C1: Locked " + r + " rows");
try {
    r = stat2.executeUpdate("DELETE FROM TEST");
    System.out.println("C2: Deleted " + r + " rows");
} catch (SQLTimeoutException e) {
    System.out.println("C2: Timeout");
}
try {
    System.out.println("C1: Updated " + stat1.executeUpdate("UPDATE TEST SET V = V + 1") + " rows");
} catch (SQLTimeoutException e) {
    System.out.println("C1: Timeout");
}
conn1.commit();

Before your changes connection 1 is able to update previously locked rows:

C1: Locked 2 rows
C2: Timeout
C1: Updated 2 rows

After your changes it isn't possible any more:

C1: Locked 2 rows
C2: Deleted 2 rows
C1: Timeout

[andreitokar]

I think that I fail to understand the very purpose of this PR.
Is it an attempt to improve concurrency, as it sounds from

if the transaction is not committed yet another transaction should not wait

But with current multi-version implementation it is not waiting to get the value, just gets committed value, which existed before that not yet committed change, not a current uncommitted value.
READ_UNCOMMITTED allows (but not mandates) to read uncommitted value for the sake of possible performance gains. But is this case - there is nothing to gain here!
That is why implementation of READ_UNCOMMITTED in H2 has practically no differences from READ_COMMITTED.

[fusunc]

We found the problem of not handling transactions correctly in our tests, thank you for your time.