Mike Matrigali updated DERBY-47:
--------------------------------
I took a look at the diffs in readlocks and I believe all are "correct" with
respect to your changes.
Thank you very, *very* much for such a detailed review of the readlocks diff,
Mike. Not only does this answer the question of whether or not the diffs are
acceptable, but I also learned a bit about how this test works, which is great.
<snip very useful details on the readlocks diff>
13) @@ -22639,8 +22639,6 @@^M
o diff ok
o not as good a test as 10. Because of previous key locking and the very
small data set both before and after we lock the same number of rows.
Diff does show difference in processing between before and after. If
there had been more than one row between 5 and 7 with the non-unique
index it would have shown less rows locked under new code vs. old code.
Just out of curiosity, the diff for this one is:
@@ -22639,8 +22639,6 @@
APP |UserTran|ROW |1 |S |A |(1,1) |GRANT|ACTIVE
APP |UserTran|ROW |1 |S |A |(1,10) |GRANT|ACTIVE
APP |UserTran|ROW |1 |S |A |(1,11) |GRANT|ACTIVE
-APP |UserTran|ROW |1 |S |A |(1,12) |GRANT|ACTIVE
-APP |UserTran|ROW |1 |S |A |(1,13) |GRANT|ACTIVE
ij> next scan_cursor;
A
-----------
When I saw this I though that the new code was, in fact, locking fewer rows than
the old code (because the last two locks are missing from the lock table). But
it sounds like that's not really what's happening?
If there's an easy explanation behind this and you have the time/inclination to
elaborate, could you perhaps touch on what we would expect to see with a query
such as "IN (1, 7)", and how that would be different from the above?
If that's too much to ask, no problem--you've already helped me a great deal by
looking at the diff and providing feedback. Just piqued my curiosity, that's all :)
Thank you again,
Army
