Re: Concurrency in an RDB

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sat, 09 Dec 2006 03:43:35 GMT
Message-ID: <Hhqeh.30339$cz.457392@ursa-nb00s0.nbnet.nb.ca>

David wrote:

> Bob Badour wrote:
>

>>David wrote:
>>
>>>Bob Badour wrote:

>
> [snip]
>

>>>In any case, restricting yourself to transactions that are local to the
>>>process managing the DB, can you outline a realistic example where
>>>long-lived mutative transactions are necessary?
>>
>>Why should we restrict ourselves to a tiny special class of applications?

>
> Did you actually read my last post? The "restriction" arises from an
> alternative, general approach to distributed computing.

Yes, I read that. At best, it showed you are confused on terminology. The approach you advocate actually requires long write transactions not short ones especially when a transaction necessarily spans multiple distributed systems.

>>>>>Note that my premise is that concurrency is only needed for CPU
>>>>>intensive tasks and that these only require shared read access.
>>>>
>>>>That is one of your assumptions that is false.
>>>
>>>Can you show that?
>>
>>With all due respect, your assumption is not reasonable on its face. If
>>you think it is reasonable, the onus lies on you to demonstrate its
>>reasonableness.

>
> My claim can't easily be proven true, but it should easily be falsified
> if it turns out to be wrong.

Like any other crank, you reverse the onus of proof. If you had ever bothered to read the existing literature, you would know that it has already been falsified years ago.

   You haven't yet provided an example.

Nor will I. You may open any book on transactions. Jim Gray wrote one a decade or two ago that would suffice.

It appears you made your decision. Plonk!

[remainder snipped unread] Received on Fri Dec 08 2006 - 21:43:35 CST