db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: LOB locking
Date Thu, 18 Feb 2010 12:30:50 GMT
On 18.02.10 12:07, Kristian Waagan wrote:
> Hello,
> I discovered something I think is a bug and then I wrote a test to 
> verify this. However, now I'm slightly confused :)
> Can anyone help me check if the test is correct, and maybe more 
> important, what's the expected behavior?
> The tests are basically doing the following, using variations over 
> isolation levels, autocommit state (when selecting) and result set 
> getter methods:
>  - insert an integer and CLOB value (using a stream, longer than one 
> page)
>  - select the row, access the CLOB somehow
>  - open a second connection, try to delete the CLOB row
> With the current version of the test, 4 out of 24 test cases fail. The 
> causes are not identical, and there are differences between the 
> embedded and the client driver. With an earlier revision of the test I 
> verified [at least some of] the failures back to 10.2 (didn't try 
> 10.1). I think I understand some of the failures, but I'd like to 
> clarify the expected behavior before I do anything more.
> There are some TODOs in the test. A few questions:
>  a) Should a LOB be protected by an  "extra" lock even in 
> READ_UNCOMMITTED to keep it valid until the end of the transaction?

Found a comment regarding this in DERBY-3098:
"I assume we also for READ_UNCOMMITTED want the record of the Blob to
be locked since the Blob object should be stable regardless of
isolation level. (I think this illustrate that locking the record is
not the best solution for guaranteeing stability, but creating a new
mechanism that allow more concurrency will be much more work. More
work than I am willing to put into this.)"

And my question above should of course read "... to keep it valid until 
the end of the transaction or until it is explicitly freed?"
One drawback of this approach is that code processing a large number of 
LOBs in a JDBC 3 environment with autocommit off won't have a way to 
explicitly free LOBs as the processing progresses. This is not a problem 
in JDBC 4, which has [BL]ob.free(), and the problem may be worked around 
in JDBC 3 by issuing periodic commits/rollbacks (may not be applicable 
in all cases, depends on application).

Regarding the alternative solution mentioned in the comment above, I 
guess we would have to implement a kind of copy-on-write mechanism (may 
not be as expensive as it sounds, but would add complexity to store).


>  b) When doing rs.getCharacterStream(2) on a CLOB column, do we still 
> want to set the "extra" lock?
> FYI; the test goes into 
> java/testing/org/apache/derbyTesting/functionTests/tests/store/
> Thanks,

View raw message