Re: "Transactions are bad, real bad" - discuss
Date: Wed, 30 Apr 2003 14:18:03 -0700
Message-ID: <b8pec1$ces2s$1_at_ID-152540.news.dfncis.de>
Paul, I'm willing to give you a pass to almost all what you claim, although you have to provide more substance, so I'll give you a pass "in principle it can be done, the results are unclear". Do you have a published paper somewhere ?
But to my pertinent and very general example, you haven't responded instead raised a different example, which by the way can be resolved trivially, even with the current DB2 and transaction.
>>Here's a deal: I reserve a sum to be debited against a client account >>(the sum is not debited yet, just the available balance reflects the >>reservation - i.e. the client has committed to pay). Based on some other >>happenings in the client software (let's say I cannot performa the >>service, or I can, etc), I want either to go ahead with the debit, or >>cancel the transaction (ROLLBACK). Compose several of these happening >> >>BEGIN >>db->DB_STATEMENT1 >>client->ACTION1 >>db->DB_STATEMENT2 >>client->ACTION2 >>db->STATEMENT3 >>END >> >>Where each consecutive action depends on some results of the previous >>action, and at each point in time client should be able to decide a >>rollback.
>
>
> It seductive isn't it, this rollback ability. A counter example.
It is not seductive but very efficient in terms of development cost and in terms of factoring out functionality that in your model will have to be shifted to be a burden for your users.
What about the mere commit statements ? Not only rollback, but just commit, how do you make the client computation part of the single database statement ?
As for your example, that's a trivial problem to solve:
>
> db->DB_STATEMENT0 INSERT INTO 3G_Auction_Bid ('Network2', $11Billion')
> BEGIN TXN
> db->DB_STATEMENT1 INSERT INTO 3G_Auction_Bid ('Network2', $12Billion')
> client->ACTION1 Wait for 2 mins // end of the auction //
> db->DB_STATEMENT2 SELECT winning_bid FROM 3G_Auction_Result
> client->ACTION2 If winning_bid > $11Billion THEN
> db->DB_STATEMENT3 COMMIT ELSE ROLLBACK END
> END TXN
>
> Would you allow that in your DBMS? If not how to avoid it? Vet all
> applications using your DBMS! What an overhead.
>
First fo all, the code above is incorrect with regards to probable business rules. To protect against bad developers, I doubt there is any model in the world that could do that. The second the insert if itb gets the lock, will prevent anybody else from submitting bids, and so on, so forth
Second you can make the client automatically rollback if he violates business rules, by using triggers, you can design a special column to get the timestamp of the transaction, create special rules to autocommit for particular transactions, and so on so forth.
>>>My short answer is, if the 'client programmer' want to freeze time then >>>tough - that is not allowed in this model of reality. >>> >> >>Tough luck indeed. So we are back to using better models of reality. >>Like transactions.
>
>
> One of my key points is that
>
> ** Transactions are not a good model of reality **
>
> Rollbacks are not a good model of the world. I can think of no example where
> I can perform some actions in the real world and then decide that I did not
> actually want to do them and so roll them back. I cannot do things and expect
> others to not be able to see them until I'm happy and commit them. Heck I
> wish I could, but we cannot freeze time, nor wind time back and undo what we
> have done. In reality we reverse things by taking compensating actions. I if
> withdraw too much money from my bank, I cannot 'roll back' my action, rather I
> need to deposit some of it back.
>
Yes, so most of the time these compensating transactions can be taken automatically by the database, while also taking care of concurrency and isolation issues. That's why we have so much theory on the subject.
Now you want me to write code to do all these ? Forget about it.
When I need a special case, I'll commit my transactions sooner rather than later, or even have the autocommit turned on, and I shall write code for special cases.
>>Well, another reality check for you: not all participants in distributed >>systems are databases. Even if some are databases not all need to >>support relational algebra.
>
>
> Every 'system' participating in a distributed relational database, needs to be
> able to masquerade as a database, needs to support the common relational
> algebra. This is trivially true.
>
This is trivially true in your theory, in reality it is trivially false. And for good reasons :)
> Would my transactionless model make such masquerading more difficult for
> existing systems? Pass. Is it more difficult to add transactions to a
> non-transactional system, or to hide all evidence of transactions from a
> transactional system? Pass (although I suspect the latter).
>
> If you have a 'distributed system' that is not trying to be a distributed
> relational database, then you can use whatever logical model you so desire,
> including say a logical concept of transactions.
>
Yes, but I'll not be able to integrate that system wityh your transactionless database. You know transaction theory is not confined to the universe of databases. They are an essential ingredient in the construction of many distributed algorithms.
>
>>Therefore you cannot say >> >> BIG_VALUE_OFTHE_WHOLE WORLD := NEW_VALUE_OF_THE_WHOLE_WORLD
>
>
> If I had a distributed relational database that supported my model, then yes,
> I darn well could do exaclty that. If I could not do that, it would not be a
> distributed relational database that supported my model.
>
>
>>Imagine the scenario above with DB and client, compounded by several >>participating resource managers.
>
>
> Merely implementation issues (assuming you would want to attempt such a task
> with existing systems. I'd just migrate any existing data and business rules
> to some new, easier to integrate, databases)
>
Those mreley implementation issues, should lead you down the path that some implementation issues in design of advanced programming languages proved to be provably unsolvable.
>>I perform an update, I get some results back, do a computation >>in the client, depending on my results, I'll issue some more updates, or >>I want to issue a rollback.
>
>
> I count at least 2 updates there.
>
Both of them plus the computation on my side have to be atomic.
>>> >>>This is no different from today. Well it is different as many existing
>
> DBMS
>
>>>systems do not respect the rule that transaction timestamp order needs to >>>agrees with transaction serialization order. Banning transactions makes >>>keeping to this rule much easier to implement. >> >>Yes. You just shifted the burden to the client programmer.
>
>
> Which burden? Although I probably agree with you. My model does, in places,
> require more work by users (and removes work from them in other places), but
> all the extra work is work to fully define the business rules of their
> database, rather than delegating some of the rules (such as choose of locking
> protocol) to the DBMS and it's often arbitrary and inflexible defaults and
> options.
>
>
I thibnk you seriously need to contemplate and quantify what this "extra work" means in a systematic way.
I hope it was a typo error when you implied we should not delegate things like choosing the locking protocol. As inflexible as that is in the DBMSes of today, it is correct and it works.
Delegate that to the user and then you'll see troubles.
>>No, you made a claim, you have to provide at least as good mechanism as >>transactions do.
>
>
> Agreed. I do provide a good as mechanism, well it's a lot better actually.
Well, if you do provide that mechanism all is left to do is present that to us. What you presented so far is extremely unconvincing and rather flawed in my opinion.
Best,
Costin Cozianu
Received on Wed Apr 30 2003 - 23:18:03 CEST