[
https://issues.apache.org/jira/browse/DERBY-6761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14170606#comment-14170606
]
Knut Anders Hatlen commented on DERBY-6761:
-------------------------------------------
Hi Karl,
I think the described behaviour is per design. The Blob object is accessible
until the transaction is finished or the Blob is explicitly freed by calling
free(). The lock must be held until the object is no longer accessible, in case
you'll want to read more data from it. For BLOBs less than 32k, the entire
value is cached in the Blob object, so there will be no need to read more of
its data from the database, and the lock can be released earlier.
If the extra lock causes problems for your application, I think your options
are:
1) call free() when you're done with the Blob
2) use another accessor method than getBlob(), such as getBinaryStream() or
getBytes()
> Closing resultset after retrieving a large > 32k value lob does not release
> locks
> ---------------------------------------------------------------------------------
>
> Key: DERBY-6761
> URL: https://issues.apache.org/jira/browse/DERBY-6761
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.10.2.0, 10.11.1.1
> Environment: Windows 8.1, Windows 7, jdk 8
> Reporter: Karl Griesser
> Priority: Critical
> Attachments: Main.java
>
>
> Same issue as in https://issues.apache.org/jira/browse/DERBY-2892 but seems
> to have made it into 10.0.2.0
> I've create a simple java that
> *) creates a database + table.
> *) inserts data (first round 10k blob)
> *) select with close rs and close statement
> *) prints locks
> *) inserts data (first round > 32k blob)
> *) select with close rs and close statement
> *) prints locks
> In the scenario with the 32k blob the Shared Lock on the row is not released
> until the transaction is commited.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
