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 LOB locking
Date Thu, 18 Feb 2010 11:07:09 GMT

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?
  b) When doing rs.getCharacterStream(2) on a CLOB column, do we still 
want to set the "extra" lock?

FYI; the test goes into 


View raw message