You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Thomas Niessen <th...@scopevisio.com> on 2007/06/29 11:14:32 UTC

How to force release of row locks on conjunction with LOBs w/o using commit

Hello!

Configuration:
Derby 10.2.2.0 in network mode (client/server), Java 6

Is there any way to force Derby to release shared row locks on rows
containing LOBs even though the transaction which accquired them is
still active and has not committed?

My application is reading from a table containing a LOB column (a BLOB
to be precise) in transaction A using connection 1. While shared row
locks are released after stepping through the rows in the result set
this does not apply rows containing blob objects above a certain size.
So the locks remain even after the result set has been closed (see also
http://java.sun.com/javase/6/docs/api/java/sql/ResultSet.html#close()).
After A has completed processing the result set including streaming of
the BLOBs but is still active, now comes transaction B using connection
2 and tries to update a record on which A is holding the lock, which of
course results in an exception. Unfortunately, I cannot commit on
connection 1.
Is there any way I can force Derby to release the locks of A? 

There is another thing:
While Derby seems to comply with the JDBC specs on this matter there is
one thing that strikes me a little odd: Transaction A seems to accquire
a lock only if the BLOB value is above a certain size. For small BLOBs
(<1KB) no row locks are created. What is the mechanism behind this
behaviour and can I use it in any way to solve my problem?

Thanks for your time.

Best regards,
  thomas