Re: MV Keys

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sat, 04 Mar 2006 08:45:58 +0100
Message-ID: <44094530$0$11065$e4fe514c_at_news.xs4all.nl>


vc wrote:

> mAsterdam wrote:

>>vc wrote:
>>>mAsterdam wrote:
>>>>vc wrote:
>>>>>mAsterdam wrote:
>>>>>>Marshall Spight wrote:
>>>>>>>Jon Heggland wrote:
>>>>>>>
>>>>>>>The relational operators don't handle lists very well.
>>>>>>>
>>>>>>>myList.removeAt(3)
>>>>>>>
>>>>>>>vs.
>>>>>>>
>>>>>>>BEGIN
>>>>>>>delete from MyList where Index = 3;
>>>>>>>update MyList set Index = Index - 1 where Index > 3;
>>>>>>>COMMIT
>>>>>>
>>>>>>
>>>>>>Aside (the example surely illustrates your point)
>>>>>>could this removeAt operation possibly be useful
>>>>>>in a concurrent environment?
>>>>>>
>>>>>>You'ld never know which item you are going to scratch -
>>>>>>somebody else could have just done myList.removeAt(2).
>>>>>
>>>>>
>>>>>What happened to concurrency contro in your hypothetical system ?
>>>>
>>>>Assuming MVCC the item which was the third item
>>>>in MyList at transaction time would be removed.
>>>>Results may be very unpleasant - that was my point -
>>>>but would this constitute a CC failure?
>>>
>>>Sure it would. It would mean that your database CC is broken.
>>
>>In what way? Please explain.
> 
> 
> If the CC implementation allows the result of several parallel
> transactions modifying the database to be *not* equivalent to some
> serial execution of the same transactions,  the implementation is
> surely broken because it clearly does not achieve its goal of ensuring
> such equivalency.

So we still have the question what the useful effect of OurSharedList.removeAt(3) should be.

(originally myList.removeAt(3), but I renamed it in another subthread to emphasize the multi-user/threadedness)

Extrapolating, ISTM your answer to the question: "could this removeAt operation possibly be useful in a concurrent environment?" would be
that it is irrelevant:
removeAt(index) isn't even valid under concurrency.

Am I understanding your point correctly? Received on Sat Mar 04 2006 - 08:45:58 CET

Original text of this message