db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Pendleton <bpendle...@amberpoint.com>
Subject Re: [jira] Created: (DERBY-3098) LOB locks are not released after free().
Date Wed, 03 Oct 2007 14:19:53 GMT
> When getBlob/getClob is called on the ResultSet, the current row is
> locked if the JDBC driver does not cache the entire LOB value in
> memory.  This is done to prevent the Blob/Clob object from being
> changed.  

I'm confused about a rather naive question (I don't have very much
experience with LOBs): is there any other way for another transaction
to access the Blob/Clob except via the base record of which the Blob/Clob
is a part?

And, if the only way to get to the Blob/Clob is via the base record,
isn't the lock on the base record sufficient to prevent any other
transaction from accessing the Blob/Clob?

Or, are you saying that the JDBC semantics are that my application
can navigate away from the base record, and if I am using, say,
READ COMMITTED isolation level, then the lock on the base record is
then released, but the lock on the Blob/Clob is supposed to be
retained until either:
  - the transaction is committed/rolled back, or
  - my application calls Blob.free()

Does that mean that another transaction could succeed in locking
the base record, but be unable to access the Blob/Clob because it
was still locked by my original transaction?



View raw message