Re: Concurrency in an RDB
Date: 8 Dec 2006 21:54:47 -0800
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.
> >>>>>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
> > 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