Dude, you're a hardware vendor's wet dream.

The point of having spare cycles is that the machine is now free to do other
tasks and at the same time have the head room to grow as the company grows
or the amount of data tossed at the application grows.

__________________________________________________ _______________
Make every IM count. Download Messenger and join the i’m Initiative now.
It’s free. http://im.live.com/messenger/im/home...e=TAGHM_June07

DA Morgan wrote:
DB2 has, so many of the features you allude to are already present (like
DECODE, UNIQUE, Oracle sequence syntax...). also IDS has "readers don't
block writers, ..." which eliminated the perhaps single biggest
stumbling block for porting Oracle apps.

Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

Serge,

Got me to want to actually ask you a question. :-)

It's my understanding that all other DBMS products are pessimistic-locking, ORACLE
is optimistic-locking, Oracle being only one in this category of mainstream DBMS products
to have optimistic locking.

Does this mean Informix has both pessimistic _and_ optimistic locking?

Thanks,

-t-

Serge Rielau wrote:

On Mon, 2007-06-18 at 11:26 -0700, Tool wrote:
In Cheetah, yes:
http://informix-technology.blogspot....committed.html

--
Carsten Haese
http://informixdb.sourceforge.net

Tool wrote:

true definitions.
To me optimistic locking is an entirely different beast and Informix had
support for it for years and DB2 Viper 2 is introducing it.
Optimistic locking (as I understand it) is commonly used in three-tier
architectures where the business transaction is much longer than the
database transaction. Note that in that space all products are on an
equal footing since no vendor can handle isolation across transactions.
In fact I think SQL Server is the most aggressive user of optimistic
locking for many years with deep support in .NET. Perhaps this is fueled
by the default auto-commit behavior (??)

Ticket purchase at an airline is a typical example for optimistic locking.
You look for a seat going from A->B and you get a set of possibilities
back. Having that information stashed away you check with your
significant other if she agrees and eventually pick one of the option
and hit "book". Two things can happen (actually make that three):
1. All is well you get the seat "confirmed!"
2. You get the seat but the price has changes "Confirmed?"
3. Oops, that seat is gone, try again.
Why? There never was a reservation for any of the seats!

IDS "natively" supports this sort of logic by supplying change
timestamps. The app keeps these around and when update time comes around
the change time stamp is compared to what's in the database.
This approach is "optimistic" in the sense that it assumes that the
stamps will match and you get that seat.

Now, within a transaction a similar scheme can (but not must) be used in
a multi version concurrency control situation. This would imply that a
cursor for UPDATE does not acquire an intend-update lock and the UPDATE
itself may fail if the row has changed between the FETCH and the UPDATE.
To do this reliably a change time stamp must be available for each row
in each table. To the best of my knowledge Oracle records these on a
page level however (i.e. an undosegments have a page granularity, not a
row granularity). But I'm sure Daniel or Mark T. would be more qualified
to comment than I am.

In IDS Cheetah READ COMMITTED is a variation on cursor stability and I
do not think that it uses optimistic locking either. I'm sure Madison or
Jonathan can confirm or dispel my assumption that an intent-update lock
will be used since a very fast transaction could otherwise come in
between the FETCH and UPDATE and COMMIT with no way of the cursor being
notified.

I can't say I'm an expert in locking and isolation level. But hey I
tried :-)

Cheers
Serge

--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

Thanks Serge.

My training has been primarily non-Oracle, meaning that I've learned to
program outside the database, whereas it's my impression that Oracle folks
program applications with a high dependence on the database engine, thusly
why I'm convinced that you can't compare most other database products with
Oracle simply because it's a lot different than most. What I'm gathering
is that it looks like Informix got a big boost in features, but to appreciate
these features you really have to understand how a lot of applications work
that are being used by the big database companies, i.e., SAP, etc. So for
me until I see a benchmark comparison of applications and some specific
task that is compared, I think basic I vs O comparisons are not realistic,
and only superficial at best.

Thanks for your insight...

-t-

Serge Rielau wrote:

Hi t,

I'm not Serge, but the answer to that is yes.

As of 11.10, you can have pessimistic-locking, or optimistic locking.

Entirely configurable at the instance level.

The onconfig parameter is

USELASTCOMMITTED




----- Original Message ----
From: Tool <tool (AT) thetool (DOT) com>
To: informix-list (AT) iiug (DOT) org
Sent: Monday, June 18, 2007 1:26:57 PM
Subject: Re: Informix beats Oracle

Serge,

Got me to want to actually ask you a question. :-)

It's my understanding that all other DBMS products are pessimistic-locking, ORACLE
is optimistic-locking, Oracle being only one in this category of mainstream DBMS products
to have optimistic locking.

Does this mean Informix has both pessimistic _and_ optimistic locking?

Thanks,

-t-

Serge Rielau wrote:
_______________________________________________
Informix-list mailing list
Informix-list (AT) iiug (DOT) org
http://www.iiug.org/mailman/listinfo/informix-list

On Jun 18, 9:36 am, "Obnoxio The Clown" <obno... (AT) serendipita (DOT) com>
wrote:
since i do this for a living, i guess i have some experience in that
area. i've certainly come across examples where 1 DBMS truly out
performs another for a particular query or set of queries, but, in my
experiece of running hundreds of comparisons, i rarely see a
significant difference that would lead me to believe 1 DBMS is
significantly better than another... at least in terms of raw OLTP
power.

your reference to discrete transactions wasn't really what I was
thinking, although that's a good one. probably one of the biggest
benchmark specials that all the players use is hashing (DB2 has Range
cluster, etc...). IDS does not support a hashed access method thus
making it impossible to compete in the TPC (a,b,c) arena.

Serge Rielau wrote:
I thought the single biggest stumbling blocks was IBM management.

That's certainly what I hear.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu (replace x with u to respond)

"Data Cruncher" <dcruncher4 (AT) aim (DOT) com> wrote

This is a nonsense though, isn't it? Every vendor can pull out an example
of a world-renowned system that runs on its database.