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 Mon, 27 Feb 2006 12:35:14 GMT
Mike Matrigali wrote:
> I was not aware of the alter table dependency check for offline
> compress, this must be outside of store somehow  - maybe something
> tied to all alter table statements.  It may make sense
> to change online compress to hook up with whatever offline compress
> is doing to make this happen.
> Just testing the current system does not mean that future changes
> won't break SUR.  Unless we agree to change the contract on unlocked
> RowLocations, then it still isn't right for code to depend on
> an unlocked RowLocation not ever pointing to the wrong row - because
> of the issue with truncate.   Some possible issues with your test
> in the online compress case:

I think you previously said:
    In current access methods this could be enforced this while holding a
    easily if the table level intent
    lock requirement is added.
    I would be comfortable adding this to store contract.  It
    seems reasonable and allows coordination through locking. "

I therefore think it would be good if the  contract said:
  * truncate and compress requires exclusive table locking
  * the truncate, purge and compress operations do not share any locks 
with user transactions

Are you ok with adding this to the contract ?

> 1) online compress has 3 separate phases, all of which do different
>    types of locking.  Some use internal transactions, which explain
>    the conflict lock.  I would try the following test:
>    o autocommit off
>    o hold cursor as your example, with a next
>    o commit transaction
>    o execute in place compress now that hold cursor has released all 
> it's locks.

This is exactly the problem for the holdable case: truncate. After 
truncate, a Page can be recreated, and RowLocations may be reused on the 
new page. This should not be a problem for the non-holdable case, since 
we will hold the table intent lock.


> Andreas Korneliussen wrote:
>> Andreas Korneliussen wrote:
>>> Daniel John Debrunner wrote:
>>>> Andreas Korneliussen wrote:
>>>>> Problem:
>>>>> 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.
>> It seems to me that that online compress will not use the same 
>> transaction:
>> ij> autocommit off;
>> ij>  get cursor c1 as 'select * from t1 for update';
>> ERROR 40XL1: A lock could not be obtained within the time requested
>> ij> rollback;
>> Offline compress is rejected if executed from the same connection:
>> ij>   get cursor c1 as 'select * from t1 for update';
>> ij> next c1;
>> ID
>> -----------
>> 1
>> ERROR 38000: The exception 'SQL Exception: Operation 'ALTER TABLE' 
>> cannot be performed on object 'T1' because there is an open ResultSet 
>> dependent on that object.' was thrown while evaluating an expression.
>> ERROR X0X95: Operation 'ALTER TABLE' cannot be performed on object 
>> 'T1' because there is an open ResultSet dependent on that object.
>> ij>
>> Are there other user-visible mechanisms to start online compress ?
>> If not, I think we could conclude that there are no known issues with 
>> the use of RowLocation in non-holdable SUR (given the discussions 
>> about validity of RowLocation in separate threads)
>> Andreas
>>> 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.
>>> Andreas

View raw message