db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Korneliussen <Andreas.Kornelius...@Sun.COM>
Subject Re: conflict detection strategies
Date Wed, 15 Feb 2006 15:24:55 GMT
Daniel John Debrunner wrote:
> Andreas Korneliussen wrote:
>>For holdable cursors, we will release the table intent lock when doing
>>commit on the transaction for the cursor.
>>The table intent lock, prevents the system from doing a compress of the
>>table, causing all RowLocations to be invalid. In addition, it prevents
>>reuse of RowLocation for deleted + purged rows.
> I think this last paragraph is an incorrect assuption. The table intent
> lock prevents other transactions from doing a compress, but not the
> transaction holding the lock.

That is a good point.

The main problem would be the system doing a compress, however we should 
take into account the fact that the user can run compress from the same 
transaction, and then maybe invalidate the resultset, or prevent the 
compress from running.

> I think there are other situations where the RowLocation will become
> invalid, such as the transaction deleteing the row.

Yes, however as far as I understood, the RowLocation would not be reused 
as long as at least some sort of table level intent lock is held, and 
the store will simply return false if one tries to do update / delete / 
fetch on a RowLocation which is deleted, or deleted+purged.


View raw message