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
