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).
--
Kristian
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,
