Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Tue, 28 Feb 2006 11:45:55 +0100
From: Andreas Korneliussen <Andreas.Korneliussen@Sun.COM>
Subject: Re: conflict detection strategies
In-reply-to: <44032DCE.3070900@sbcglobal.net>
To: derby-dev@db.apache.org
Reply-to: Andreas.Korneliussen@Sun.COM
Message-id: <440429E3.8080700@sun.com>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050930)
References: <43F1BEF6.6020301@sun.com> <43F3388A.9060500@apache.org>
 <43F347C7.4040501@sun.com> <43FC379F.8080301@sun.com>
 <43FF87BF.6010302@sbcglobal.net> <4402F202.4010703@sun.com>
 <44032DCE.3070900@sbcglobal.net>

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