Re: "Transactions are bad, real bad" - discuss

From: Peter Koch Larsen <pkl_at_mailme.dk>
Date: Wed, 30 Apr 2003 10:03:11 +0200
Message-ID: <3eaf833f$0$42612$edfadb0f@dread11.news.tele.dk>

"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> skrev i en meddelelse news:b8ljgd$383i$3_at_gazette.almaden.ibm.com...
> "Jonathan Leffler" <jleffler_at_earthlink.net> wrote in message
> news:3EAE16E6.2070803_at_earthlink.net...
> > In an article under the thread "Do Data Models Need to [be] built on a
> > Mathematical Concept?", Paul Vernon commented:
> > >>transactions
> > >
> > > Dead wrong. Transactions are bad, real bad. In short they are not
> > > compatible with the 'arrow of time'. They let you freeze time and
> > > that is not a good model of reality. Start a new thread if you want
> > > to discuss the details, I've a draft paper on the subject and a
> > > could do with some intelligent challenges to sharpen up my
> > > argument.
> >
> > Herewith, a new thread - unless someone else got there first.

>

> Thanks for starting the thread Jonathan (and Marshall also).
>
[snip]

>


> Imagine the business rule:

>     'all bids must be made within 1 hour of the auction opening'

>

> With transactions, this rule is compromised. A user could simply open a
> transaction before the end of the 1 hour deadline, make a bid at then only
> decide to commit (or rollback) the bid at his leisure after the end of the
> deadline.

>

> With transactions you cannot get 'strong application independence' - the
> database cannot stand alone and be used by just any old application or
> interfere.

>
>

> The argument above is probably the most cutting against transactions, but
I
> have many others... I think I'll leave them to later...

Hi Paul

I remember this being brought up before and will remind you that your model does not prevent malicious users from getting the effect mentioned above. As a simple example, the malicious user could issue the statement

MAKE_A_BID,
SIT_IDLE_FOR_48_HOURS; SIT_IDLE_FOR_48_HOURS would not necessarily have to be an idle loop, of course. It could just as well be some other time-consuming DBMS-action such as importing a digitalized movie from a source with a slow connection or doing some huge query/update against some other tables.

Kind regards
Peter Received on Wed Apr 30 2003 - 03:03:11 CDT