Re: Transactions: good or bad?

From: Paul Vernon <paul.vernon_at_ukk.ibmm.comm>
Date: Thu, 8 May 2003 10:36:28 +0100
Message-ID: <b9d8pf$3dhg$1_at_gazette.almaden.ibm.com>


"Todd Bandrowsky" <anakin_at_unitedsoftworks.com> wrote in message news:af3d9224.0305071501.4eccbed5_at_posting.google.com...
> >
> > You'll have to point me to where I have argued against serialization. I
can't
> > recall that I have.
>
> I seem to have inferred from your posts that transactions were not
> good because they do not properly follow the "arrow of time".

Indeed I have said that is one reason why transactions are not good

> Yet,
> transactions are part and parcel rooted in serialization theory,

And in the worst case, transactions can only be serialized by actual serialization. All the optimisations in the world don't help when CURRENT TIMESTAMP needs to be fixed early in a wide ranging transaction and the COMMIT/ROLLBACK comes much later when the user/application feels like it. ROLLBACKs break the "arrow of time" because the database time is logically frozen once CURRENT TIMESTAMP is fixed in a transaction, but real, outside world time continues so that the later COMMIT/ROLLBACK decision effects the contents of the database at that earlier frozen database time. All the optimisations in the world fail in the face of badly or maliciously coded user transactions.

> so
> I'm not really sure what you are after!

  1. Removing the concept of transactions from the Logical Relational Data Model. It is unnecessacary, redundant and harmful. We were "sold a bill of goods" back in the day. We should get rid of them now.
  2. A Logical Relational Data Model that is thus, cleaner, more powerful and can provide for complete independence of databases from applications.

[snip]
> But that implementation requires a transaction, does it not? In your
> case, you have, two users writing a change to the base data, then,
> both want to take the results and re-update the underlying data. To
> do that means some sort of synchronization, locking, etc, At least,
> internally.

At least internally. Yes. Internally you can use whatever you like to ensure consistency. I have been at pains to point out that I'm not against transactions per se, just those exposed in the Logical Data Model.

> As soon as you that "Atomic word", all sorts of rules kick in. It
> means transaction, it means concurrency control. So, what's the real
> advantage. I mean, you are either surfacing a transaction to the user
> or doing it under the covers and I don't know how that buys you much,
> except for the convenience to the user.

That 'user convenience' is in fact a simpler, more elegant and more powerful version of the Relational Model. The model is significantly complicated, and a poorer model of the world, if transactions are exposed.

> The only way, that I see, to really avoid transactions and have
> maximum concurrency is to not allow derived data to be stored at all.

Like the fact that if you have a single CPU, then a single instruction is sterilised by definition? So as long as every database action is a single CPU cycle, then you get maximum concurrency?

> >
> > [snip]
> > > >
> > > > Semantic optimisation is a general ability of any well implemented
RDMBS.
> > >
> > > Yes, but you have to implement that RDBMS on top of a server first.
> >
> > You are confusing databases with DBMSes.
>
> No, not at all. Blink. I meant what I said. Instead of having a
> database / concurrency engine that uses a SQL language, I have a
> database / concurrency engine that uses a domain specific language.
>
> > I'm all in favour of people selling
> > databases (assuming that Intellectual Properties issues - i.e. stopping
people
> > ripping off your database - are fixable). Such sold databases would be
> > application/business domain specific but would all run on a standard,
generic
> > business RDBMSes.
>
> Nope. Why have the middleman and the additional complexity?

Additional complexity!!! What, compared to thousands of application specific DBMSes?

Now I do understand your argument.

    All things being equal, a specific tool will out perform a general purpose tool

But all things are never equal. The general purpose tool has the economic of scale - you can sell more so can invest more in the design and development of the tool.

Specific tools only prosper when general purpose tools are just too ill fitting for the job.

Maybe SQL is too ill fitting. The relational model itself is not.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Thu May 08 2003 - 11:36:28 CEST

Original text of this message