Re: "Transactions are bad, real bad" - discuss
Date: Wed, 30 Apr 2003 19:19:28 +0100
Message-ID: <b8p479$1lu8$1_at_gazette.almaden.ibm.com>
"Peter Koch Larsen" <pkl_at_mailme.dk> wrote in message
news:3eaf833f$0$42612$edfadb0f_at_dread11.news.tele.dk...
> 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.
>
Hi Peter. Yes I remeber the thread well ;-) and I thank you for your original point and for bringing it up here.
To restate your point:
BEGIN TXN
db->INSERT INTO bid VALUES ('My Thoughts', $0.02, now)
client->Wait(2 Weeks)
clinet-> IF RAND() > 0.5 THEN
db->COMMIT
client->ELSE
db->ROLLBACK
END TXN The short anwser (I'm getting to like short answers ;-), is that the above is a BIG problem for transaction supporting databases. It's one of the major reasons why giving users direct access to a database, in particular direct update access, is a big no-no.
The advantage of the transaction-less model is that as we have control of the code - we never wait on external application code. If problematic code is pushed into the DMBS via say user defined functions, then we could simply disallow UDFs that have problematic performance characteristics such as WAIT(), or FIND_40th_MERSENNE_PRIME() *.
However, in my model, the above would be one statement, so the BID does not need to get made until the whole statement completes. The meaning of 'make a bid now, then wait for 2 days then commit' of the transaction statement is not the same the meaning of 'in one go(make a bid and wait for 2 days)' in my single statement.
In fact, if you did execute the following single multiple update statement (using Tutorial D syntax)
Bid := Bid UNION table { row { 'My Thoughts', $0.02, now}}, Primes := Primes UNION table { row { FIND_40th_MERSENNE_PRIME() } };
Then, given a half decent DMBS optimiser that deferred the fixing of now until as late as possible, your bid would not be made for a very long time, and in the meantime there are no locks on Bid or Primes, so you are not holding up anyone else on the system.
Regards
Paul Vernon
Business Intelligence, IBM Global Services
Received on Wed Apr 30 2003 - 20:19:28 CEST