ResultSet.getBlob holds locks even with READ_UNCOMMITTED isolation level

• Key: DERBY-2990
• Type: Bug
• Status: Closed
• Resolution: Won't Fix
• Priority: Major
• Assignee: Unassigned
• Reporter: Kathey Marsden
• Component/s: JDBC
• Affects Version/s: 10.1.3.1, 10.2.2.0, 10.3.1.4, 10.4.1.3

Description

ResultSet.getBlob() holds locks even when isolation level is set to TRANSACTION_READ_UNCOMMITTED. See attached repro

 java GetBlobLocks
Exception in thread "main" ERROR 40XL1: A lock could not be obtained within the time requested
        at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
        at org.apache.derby.impl.services.locks.LockSet.lockObject(Unknown Source)
        at org.apache.derby.impl.services.locks.SinglePool.lockAnObject(Unknown Source)
        at org.apache.derby.impl.services.locks.SinglePool.lockObject(Unknown Source)
        at org.apache.derby.impl.store.raw.xact.RowLocking3.lockRecordForWrite(Unknown Source)
        at org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.lockPositionForWrite(Unknown Source)
        at org.apache.derby.impl.store.access.conglomerate.GenericConglomerateController.delete(Unknown Source)
        at org.apache.derby.impl.sql.execute.RowChangerImpl.deleteRow(Unknown Source)
        at org.apache.derby.impl.sql.execute.DeleteResultSet.collectAffectedRows(Unknown Source)
        at org.apache.derby.impl.sql.execute.DeleteResultSet.open(Unknown Source)
        at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
        at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
        at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
        at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(Unknown Source)
        at GetBlobLocks.testBlobLocks(GetBlobLocks.java:46)
        at GetBlobLocks.main(GetBlobLocks.java:11)
[C:/kmarsden/repro/getblob] echo $WS

Comments

[Tomohito Nakayama]

I think DERBY-2990 have much of something to do with DERBY-2893.

[Øystein Grøvlen]

The reason ResultSet.getBlob() causes a lock to be held, is to make
sure that the Blob object is stable. (Ref. discussion in DERBY-2892).
In other words, the decribed behavior is intended.

If this JIRA is to be fixed, we will have to implement another mechanism
than locking to guarantee stability of LOB objects.

[Kathey Marsden]

Øystein indicated that the current behavior is intentional.