Re: Change of subject: Principles of locking

"Serge Rielau" <srielau_at_ca.eye-be-em.com> wrote in message news:c4ej8c$oo6$1_at_hanover.torolab.ibm.com...

> Sad you see it that way, I wasn't wearing a marketing head for a moment.
> Locking isn't my expertise for sure, so I was hoping to learn from this
> debate.

The way I see it is irrelevant, Serge: far from me to consider myself an expert. All I can say is: what I know about locking, I learned initially from reading IBM research papers on database locking for high volume transaction processing. Then a lot from Univac. And a heap more from Prime's DBMS - one of the best Codasyl databases I've ever seen - pity they never understood how to sell it properly. Codd, Date and Pascal then provided the translation to RDBMS terms, years later.

And then a few years ago all this "serialisation" web-driven rigmarole started. It's nothing more nothing less than stating the same-old-same-old with new terms. The underlying problem is still the original and always will be (simplifying a bit):

1- You want to consistently update something, you have to lock/read it first. This is normally performed in what is termed an update (RW) transaction.

2- You only want to read something without interference from other concurrent updaters, your writers must block readers or you must have versioning. This is normally performed in what is termed a read-only (RO) transaction.

And that's very much it in a nutshell. Of course there are a million nuances related to sizes, scalability, design, etcetc. But the problem at root remains the same. Unless you have very special needs or a very unusual application. Those of course may need a special solution.

The only fundamental difference with the Oracle model that I can see (I don't agree with it - others think it's good) is they don't have the concept of a RO transaction. Their read-consistency model is restricted (by default) to the duration of each SELECT.

Most databases before Oracle (all the way back to hierarchical) differentiate between RO and RW transactions. I do recall the explanation given to me (ages ago) by Oracle for this missing difference was that SQL being a "set-at-a-time" language, one wouldn't need a RO transaction: the query could be as complex as you wanted inside a single atomic SELECT. Thereby avoiding the classical need for a RO "mode" for multiple statements. Good or bad? Who knows?

Some DBMSs allowed you to state up front what type of transaction you would be running, using a START transaction statement. Oracle doesn't have one. They were one of the first databases to lose it. I'm not yet sure if it was a good idea, but I have to accept they have been tremendously successful without it.

-- 
Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam