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, 01 Mar 2006 09:19:43 GMT
Mike Matrigali wrote:
> 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).
> 

This is what I can verify:

Purge:
ij>  get cursor c1 as 'select * from t1';
ij>   call SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 0,0);
0 rows inserted/updated/deleted
ij> rollback;

As for purge, I have also verified that after a purge, the user 
transaction holds the row locks for the purged rows.


Defragment:
ij>  get cursor c1 as 'select * from t1';
ij>   call SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 0, 1,0);
ERROR 40XL1: A lock could not be obtained within the time requested
ij> rollback;


Truncate:
ij>  get cursor c1 as 'select * from t1';
ij>   call SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 0, 0,1);
0 rows inserted/updated/deleted
ij> rollback;

So, defagment is the only operation which meets the proposed contract.

Andreas


> 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