Re: Concurrency in an RDB

Bob Badour wrote:
> 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.

It doesn't.

> >>>>>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]

Bye Received on Sat Dec 09 2006 - 06:54:47 CET