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>
>
>
> Obviously, it should be the same regardless of whether you run
> transactions concurrently or sequentially.
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.
> 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