db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: conflict detection strategies
Date Mon, 27 Feb 2006 16:50:22 GMT


Andreas Korneliussen wrote:
> 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

This seems fine, but may require changes to store code and inplace 
compress to actually support such a contract in store.  The previous
changes just documented what was already supported.

I still don't see how this helps the holdable case, I agree this helps
the non-holdable case.

> 
> 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
> 
>> 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';
>>> ij>  call SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP','T1', 1, 1, 1);
>>> 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
>>> ij>  call SYSCS_UTIL.SYSCS_COMPRESS_TABLE('APP', 'T1', 0);
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>
> 
> 
> 


Mime
View raw message