"DA Morgan" <damorgan@psoug.org> wrote in message
news:1182298306.525484@bubbleator.drizzle.com...
> Fernando Nunes wrote:
>
>> In practice, I think this has the same results. Using this, you won't
>> block when trying to read a row that has a lock (not a shared one, but an
>> insert/update/delete lock). You will get whatever was there (or
>> wasn't...) before the operation holding the lock.
>
> This would be a major step forward for Informix if this is what it
> appears to be.
>
> Can anyone confirm the following statement is true?
>
> "Reads don't block writes and writes don't block reads and only
> committed rows are visible."
>
> And yes SQL Server finally got a measure of this with 2005 whereas
> Oracle has had it for decades.

And unlike Oracle, both SS and Informix offer other isolation levels
also, which means, that developers can use them appropriately.

Data Cruncher wrote:
> "DA Morgan" <damorgan@psoug.org> wrote in message
> news:1182298306.525484@bubbleator.drizzle.com...
>> Fernando Nunes wrote:
>>
>>> In practice, I think this has the same results. Using this, you won't
>>> block when trying to read a row that has a lock (not a shared one, but an
>>> insert/update/delete lock). You will get whatever was there (or
>>> wasn't...) before the operation holding the lock.
>> This would be a major step forward for Informix if this is what it
>> appears to be.
>>
>> Can anyone confirm the following statement is true?
>>
>> "Reads don't block writes and writes don't block reads and only
>> committed rows are visible."
>>
>> And yes SQL Server finally got a measure of this with 2005 whereas
>> Oracle has had it for decades.
>
> And unlike Oracle, both SS and Informix offer other isolation levels
> also, which means, that developers can use them appropriately.

And unlike you some people read the docs.

Oracle offers other isolation levels too.
http://download-west.oracle.com/docs...t.htm#CNCPT621

If you are going to bash something at least choose a valid point on
which to bash. One thing I find fascinating about some in this crowd
is the willingness to close their eyes and throw punches.

Those of us who actually know Oracle throw them too. But ours are on
target.
--
Daniel A. Morgan
Puget Sound Oracle Users Group
www.psoug.org

> And unlike you some people read the docs.
>
> Oracle offers other isolation levels too.
> http://download-west.oracle.com/docs...t.htm#CNCPT621
>
> If you are going to bash something at least choose a valid point on
> which to bash. One thing I find fascinating about some in this crowd
> is the willingness to close their eyes and throw punches.
>
> Those of us who actually know Oracle throw them too. But ours are on
> target.

When I said SS/Informix offers other choice, it means
that the developers has a choice to bypass CPU intensive
versioning mechanism. Does Oracle offer a way to bypass
check for block versioning and then fetch from UNDO segment.
AFAIK - no. The only other choice they have is actually
worse from concurrency point of view, like SERIALIZABLE.

"Data Cruncher" <dcruncher4@aim.com> wrote in message
news:4MKdnTxfuekqc-XbnZ2dnUVZ_rKvnZ2d@comcast.com...
> When I said SS/Informix offers other choice, it means
> that the developers has a choice to bypass CPU intensive
> versioning mechanism. Does Oracle offer a way to bypass
> check for block versioning and then fetch from UNDO segment.
> AFAIK - no. The only other choice they have is actually
> worse from concurrency point of view, like SERIALIZABLE.

or it bypasses SCN check for read-only tablespaces, which
works for only read-only tables.

Data Cruncher wrote:
>> And unlike you some people read the docs.
>>
>> Oracle offers other isolation levels too.
>> http://download-west.oracle.com/docs...t.htm#CNCPT621
>>
>> If you are going to bash something at least choose a valid point on
>> which to bash. One thing I find fascinating about some in this crowd
>> is the willingness to close their eyes and throw punches.
>>
>> Those of us who actually know Oracle throw them too. But ours are on
>> target.
>
> When I said SS/Informix offers other choice, it means
> that the developers has a choice to bypass CPU intensive
> versioning mechanism. Does Oracle offer a way to bypass
> check for block versioning and then fetch from UNDO segment.
> AFAIK - no. The only other choice they have is actually
> worse from concurrency point of view, like SERIALIZABLE.

No bypass for multiversioning with the standard isolation level.
But then Oracle gains functionality Informix hasn't had, except
as an option with Cheetah. Functionality has its cost.

The reverse question from the other side is ... having fun with
row and page locking and lock escalation?

In truth the cost of multiversioning is quite small as compared
with the cost of other functionality built in during the last
several versions which few of you know about because you don't
actually study the competition you just throw random punches in
the dark.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu (replace x with u to respond)

Data Cruncher wrote:
> "Data Cruncher" <dcruncher4@aim.com> wrote in message
> news:4MKdnTxfuekqc-XbnZ2dnUVZ_rKvnZ2d@comcast.com...
>> When I said SS/Informix offers other choice, it means
>> that the developers has a choice to bypass CPU intensive
>> versioning mechanism. Does Oracle offer a way to bypass
>> check for block versioning and then fetch from UNDO segment.
>> AFAIK - no. The only other choice they have is actually
>> worse from concurrency point of view, like SERIALIZABLE.
>
> or it bypasses SCN check for read-only tablespaces, which
> works for only read-only tables.

The concept docs can be found at:
http://tahiti.oracle.com

This group's Oracle knowledge is current to version 8i. <g>
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu (replace x with u to respond)

DA Morgan wrote:
[snip]
> The reverse question from the other side is ... having fun with
> row and page locking and lock escalation?
[snip]

Thankfully, IDS doesn't do lock escalation

--
Ciao,
Marco
__________________________________________________ ____________________________
Marco Greco /UK /IBM Standard disclaimers apply!

Structured Query Scripting Language http://www.4glworks.com/sqsl.htm
4glworks http://www.4glworks.com
Informix on Linux http://www.4glworks.com/ifmxlinux.htm

-----Original Message-----
From: informix-list-bounces@iiug.org
[mailto:informix-list-bounces@iiug.org] On Behalf Of DA Morgan
Sent: Wednesday, June 20, 2007 6:20 AM
To: informix-list@iiug.org
Subject: Re: Informix beats Oracle

Data Cruncher wrote:
> "Data Cruncher" <dcruncher4@aim.com> wrote in message
> news:4MKdnTxfuekqc-XbnZ2dnUVZ_rKvnZ2d@comcast.com...
>> When I said SS/Informix offers other choice, it means
>> that the developers has a choice to bypass CPU intensive
>> versioning mechanism. Does Oracle offer a way to bypass
>> check for block versioning and then fetch from UNDO segment.
>> AFAIK - no. The only other choice they have is actually
>> worse from concurrency point of view, like SERIALIZABLE.
>
> or it bypasses SCN check for read-only tablespaces, which
> works for only read-only tables.

DAMorgan "wrote" :

> The concept docs can be found at:
> http://tahiti.oracle.com

> This group's Oracle knowledge is current to version 8i. <g>

Yeah, Daniel, and your Informix knowledge seems current to version 5.1.

Big <g>

The only difference is that we don't troll the Oracle newsgroups.

-Dave

David Buchholz wrote:
> The only difference is that we don't troll the Oracle newsgroups.

You may not. Others here do.

As I acknowleged to Marco ... my error and I knew better. I am preparing
for a major conference (http://www.psoug.org/oraday/schedule.html) next
week and I'm more than a bit tired. So my apology for pressing the Send
button without the proof-read.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu (replace x with u to respond)

DA Morgan wrote:
> Fernando Nunes wrote:
>
> Can anyone confirm the following statement is true?
>
> "Reads don't block writes and writes don't block reads and only
> committed rows are visible."
>

Not absolutely sure, if the reader is in REPEATABLE READ/SERIALIZABLE...
I will have to test it...
But in the new isolation level writers won't block readers...
The fact that Informix have been used in so many situations without this,
would contradict the importance that you (and me) give to this feature...

> And yes SQL Server finally got a measure of this with 2005 whereas
> Oracle has had it for decades.
>

Oracle and Postrgres have always had it, because their design is different.
I suppose in Oracle/Postgres writers won't block against readers in SERIALIZABLE...


--
Fernando Nunes
Portugal

http://informix-technology.blogspot.com
My email works... but I don't check it frequently...