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 Tue, 28 Feb 2006 19:19:30 GMT
ok, I agree now that it is clear this discussion was concentrating
on non-holdable case.  Can you verify that the 3rd phase only of
in place compress already meets the proposed contract (args 0, 0, 1).

Andreas Korneliussen wrote:
> Mike Matrigali wrote:
> 
>>
>>
>> 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.
> 
> 
> Note: I am here discussing the non-holdable case only.
> 
> Yes, I guess you are thinking of the part with not sharing any locks 
> with user transactions? This comes from the problem of a user running 
> online compress from the same connection as the SUR.
> 
> Truncate should be changed to run in a separate transaction, in order 
> for the store to be consistent with the proposed contract.
> 
> A minimal requirement from SUR is that defragment does not share any 
> locks with the user transaction.  If the rows cannot be defragmented, 
> then none of the pages which we have read RowLocation from can be 
> truncated. Defragment currently is in line with what we need, since it 
> runs in a separate transaction.
> 
> Purge would only affect committed deleted rows (I guess no user 
> transaction could lock these ?).
> 
>> I still don't see how this helps the holdable case, I agree this helps
>> the non-holdable case.
>>
> 
> Yes, I know this only helps the non-holdable case.
> 
> Andreas
> 
> 


Mime
View raw message