"Transactions are bad, real bad" - discuss
Date: Tue, 29 Apr 2003 06:06:56 GMT
Message-ID: <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.
I'm sympathetic to the Date/Darwen view (espoused in The Third Manifesto and in Temporal Data) that a single statement should be the scope of a transaction, once you allow what would currently be a sequence of statements to be treated as a unit -- using the SQL notation:
UPDATE Table1 SET ... , UPDATE Table2 SET ... , INSERT INTO Table3 ... , DELETE FROM Table4 ...;
All four operations are part of a single compound statement and collectively form a single transaction.
Is that anything remotely resembling what you're thinking, Paul?
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).
-- Jonathan Leffler #include <disclaimer.h> Email: jleffler_at_earthlink.net, jleffler_at_us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/Received on Tue Apr 29 2003 - 08:06:56 CEST