Thanks for the clarification Madison.

I can see where this would be something that needs a little more explaining
to the community, in a presentation of some kind. It appears that this is
going to be useful for high-volume transactions if I'm understanding this
correctly.

Thanks!!

-t-
PS thanks to the rest of you too, DC, Fernando, etc etc.!

Madison Pruet wrote:
> Tool wrote:
>> Well I guess I was thinking this was a bit more than "SET ISOLATION TO
>> DIRTY READ".
>>
>> What's the difference between that and this new feature? Now I'm
>> totally bamboozled.
>> Does this mean that in IDS you could not read a locked row at all
>> before this new
>> feature?
>
> not with committed reads
>
> Or is this just a global dirty-read setting?
>
> No
>
> Dirty Read could return a row which is part of a current transaction and
> which might be rolled back. Last committed read will only return
> committed rows. The row might be in the process of being updated or
> deleted, but the transaction will be returned the last committed version
> of the row. However, it is always a version of the row which was
> committed.
>
> M.P.
>>
>> -t-
>>
>> Fernando Nunes wrote:
>>> Tool wrote:
>>>> Fernando, thanks too for your response. I read your website article
>>>> and
>>>> it was good too.
>>>>
>>>
>>> Thanks!
>>>
>>>> I have been under the impression that this one feature is what
>>>> Oracle sells
>>>> to clients, that they have the best non-blocking database engine
>>>> available.
>>>> Perhaps this is a bit simplistic, but it is notable that
>>>> applications and
>>>> developers now have another choice of what engine to use if indeed
>>>> this is
>>>> similar to the Oracle implementation, and was not available in other
>>>> products.
>>>
>>> I'm not speaking for IBM... standard disclaimer applies, but:
>>>
>>> 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.
>>>
>>> However, the underlying implementation is AFAIK (I'm not a
>>> developer...) completely different. Oracle is a versioned RDBMS like
>>> Postgres and I believe some engines used in mySQL. Informix is NOT.
>>> The Informix implementation is simpler (quicker?). If it hits a lock,
>>> it fetches the value from logical logs.
>>>
>>> SQL server has a similar implementation if I read and understood it's
>>> documentation correctly (since v2005 if I recall correctly).
>>>
>>> From my experience as DBA, this is THE feature that developers were
>>> wishing for. From some talks with colleagues and some customers I
>>> don't find the degree of enthusiasm I was expecting...
>>>
>>> I'll be very happy if my daily customer migrates to IDS 11 and I can
>>> use this feature. I'm "tired" of explaining the locking issues to
>>> developers that were trained only in Oracle...
>>>
>>> It will also make my daily discussions (friendly) with an Oracle DBA
>>> much less boring, since we tend to fall in this specific difference
>>>
>>