Re: MV Keys

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sat, 04 Mar 2006 19:47:36 +0100
Message-ID: <4409e0bd$0$11079$e4fe514c_at_news.xs4all.nl>


vc wrote:
> mAsterdam wrote:
>

>>vc wrote:
>>
>>>mAsterdam wrote:
>>>[...]
>>>
>>>
>>>>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?
>>>
>>>
>>>No.  The concurrency is irrelevant thanks to the CC's ensuring that the
>>>concurrent execution result is equivalent to some serial execution of
>>>the same transactions.  It does not matter what kind of write
>>>operations you want to have in your database.
>>
>>"The concurrency is irrelevant"
>>In this case this goes to say 'It doesn't matter wether
>>there is concurrency or not, the effect of
>>OurSharedList.removeAt(3) is the same.'
>>
>>What should the effect of OurSharedList.removeAt(3) be?

>
>
> Obviously, it should be the same regardless of whether you run
> transactions concurrently or sequentially.

Yep. So what should it be?

> I was objecting to your invoking the ghost of concurrency:
>
> "Aside (the example surely illustrates your point)
> could this removeAt operation possibly be useful
> in a concurrent environment?
> "

I see a difference in the use of indices between a list under single control and a shared list.

> I do not know whether the operation is useful per se, you tell me.

Don't know really. Hmm... try:

The contestants ended on 2nd place ex equo. For the ceremony add a second prize for 2nd place, and remove the third prize (desired effect: 2 silver medals, no bronze medal). Received on Sat Mar 04 2006 - 19:47:36 CET

Original text of this message