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

"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).

> I assume that you're not arguing that it is unnecessary to have
> something akin to a transaction, (or a saga, or a set of compensating
> actions),

Well that is exacly what I am arguing. We do not require transations in the (logical level of) the relational model. In fact they are positively harmful.

I probably should say now that it's not transactions per se that are a bad idea, on the contrary I'm sure transactions are vital to all sorts of internal systems workings. It is transactions exposed in the relational model that are bad.

Now, I must deal with the 'ususal example', provided nicely by Jonathan.

> in the sequence:
>
> BEGIN WORK;
> UPDATE Accounts
> SET Balance = Balance - 1000000
> WHERE AcountOwner = 'Paul Vernon';
> UPDATE Accounts
> SET Balance = Balance + 1000000
> WHERE AccountOwner = 'Jonathan Leffler';
> COMMIT WORK;
>
> If the two UPDATE operations are not treated somewhat atomically - if
> the first can succeed and yet the second can fail (boo, hoo) without
> somehow undoing the first - then Paul is 1000000 currency units (GBP)
> out of pocket (and so am I, but I didn't have them in the first place,
> whereas maybe Paul did, and more significantly, maybe he now owes the
> bank those currency units he didn't already have in his posession).

As Date/Darwen would tell you, the above is in fact, i.e. is logically, one single update. In this example, even SQL (!) can treat is as so:

UPDATE Accounts

    SET Balance = CASE WHEN AccountOwner = 'Paul Vernon' THEN

            Balance - 1000000
        WHEN AccountOwner = 'Jonathan Leffler' THEN
            Balance + 1000000

The traditional problem has been when the update covers more than one table. SQL does not have a 'multiple update' syntax, so it is forced to use a transaction. But SQL is not the limit of the relational model.

In theory a transaction is atomic by definition. It is the atomic change of the database value from it's current value to a new value. Therefore a transaction is no more than a single, atomic database value update operation. If our relational model allows multiple relvar assignment, or my preference, database assignment (assigning the database variable a new database value) then we have no need of transactions.

Now, in practice a transaction is not atomic - it has components - that just happen to be applied in a 'all-or-nothing' fashion. The only remaining justification for transactions is that these components provide something useful. However this provides the contradiction at the heart of the concept's downfall

    Transactions want to be atomic, but only by being non-atomic over real time can they provide anything useful.

To solve this contradiction, they must freeze database time, even while moving forward (being non-atomic) in real time. This allows gaps to occur between database and real time, with decisions (such as whether to roll back or commit) occurring later in real time having affects on the database state at the earlier frozen time.

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

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Tue Apr 29 2003 - 12:13:53 CEST