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?

thanks,

bryan

Reply via email to