Re: Idea for concurrent transactions

Paul <paul_at_not.a.chance.ie> wrote in message news:<MPG.1ac4010dfb7951a198990c_at_news1.eircom.net>...
> ed.prochak_at_magicinterface.com says...
>
> > > I believe that Informix uses it, and also Oracle some of the time.
>
> > Just an FYI, ORACLE has used Multiversioning for a LONG time. I believe they
> > were the first to do it. At the time I first studied this, interbase was the
> > only other DBMS to also used MV.
>
>
> I'm certain that PostgreSQL also uses it, or did you only mean
> commercial databases?

"At the time" was actually referring to about 10years ago, when ORACLE 7 was released. Did PostgreSQL exist then? But actually at the time, I did just examine commercial DBMS's.

>
>
> > MV is why ORACLE is much better with large transaction volumes and many
> > simultaneous sessions/connections than most other products. Locking is just a
> > painful way of controlling access.
>
>
> My understanding is that Oracle uses a combination depending on the
> circumstances.
>
>
> Paul...

Well, use, there is occasionally some locking going on under the hood. But the closest you come to locking in the SQL on ORACLE is is a SELECT...FOR UPDATE;
Otherwise you never really think about it at the programming level.

While other DBMS products might not require you to explicitly program locks, you need to be much more aware of them, than with MultiVersioning.

Sadly I'm currently working on maintaining an application where not only must I simetimes have to programmatically handle the locks (with explicit XLOCK, and UNLOCK commands), but where there are conditions where the DBMS cannot perform a ROLLBACK correctly!!

DB Locks are not fun.
  Ed Received on Fri Mar 19 2004 - 20:18:36 CET