Re: "Transactions are bad, real bad" - discuss
From: Costin Cozianu <c_cozianu_at_hotmail.com>
Date: Tue, 29 Apr 2003 10:59:55 -0700
Message-ID: <b8mecc$bnbun$1_at_ID-152540.news.dfncis.de>
>
>
> Thanks for starting the thread Jonathan (and Marshall also).
>
>
>
>
> 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.
>
>
>
>
> 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
> END
> WHERE AccountOwner IN ('Paul Vernon' , 'Jonathan Leffler' )
>
> 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
>
>
Date: Tue, 29 Apr 2003 10:59:55 -0700
Message-ID: <b8mecc$bnbun$1_at_ID-152540.news.dfncis.de>
Paul Vernon wrote:
> "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
> END
> WHERE AccountOwner IN ('Paul Vernon' , 'Jonathan Leffler' )
>
> 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
>
>
Ok, let's say you want only single statement updates, with single statement supporting multiple database operations.
How do you integrate databases and others in a distributed transaction ?
How do you allow for rollback, possibly even in the middle of an update operation ?
Related to the above, what is your model for concurrency control ? Do you only allow for fully serializable executions ? How is database going to decide that, if instead of a peacemeal statement by statement transaction, it will have to wait somehow for the full single statement behemoth ?
This is just to begin with, depending on your responses we'll see what follows...
Best,
Costin
Received on Tue Apr 29 2003 - 19:59:55 CEST