Re: Does Informix do Versioning Read-Only Transactions?
Posted in 1995
D. Erway (derway@ndc.com) wrote: : >>>>> "gs" == Graeme Sargent <graeme@pyramid.com> writes: : D. Erway (derway@ndc.com) wrote: : : Does anyone know if any versions of Informix, (maybe the latest - 7), do : : Versioning Consistency Control like Oracle 7 does? : gs> No, Informix 7.1 does not do Versioning. But then, neither does ORACLE7. : From the Oracle 7 Server Concepts Manual, page 10-7, about Multi-version : Consistency Model, and Transaction-Level Read Consistency: : "To provide repeatable reads within a read-only transaction, ORACLE observes : the start of the transaction. For the duration of the transaction, only data : committed before the start of the transaction is available." I stand by my posting. Oracle does Read Consistency. Informix does not. If you specify read-only Oracle does transaction level Read Consistency. Neither do (what I believe should be labelled) Versioning (although I admit I missed the read-only contextual restriction in the heading of the original post). Oracle Marketing applying a label of "Multi-Version Consistency Model" to their Read Consistency capability doesn't give them versioning any more than their applying of the label "Multi-Threaded Server" gives them multi-threading. (For those who didn't realise, the ORACLE7 Multi- Threaded Server uses single-threaded processes, unlike Informix DSA) The Server Concepts Manual also conveniently (but I suppose justifiably) omits to mention the impact of Discrete Transactions or "Snapshot too old" errors on the Read Consistency model. : gs> : Or any other versioning transaction control like maybe Interbase? : gs> Now *that's* versioning! and I think Oracle Marketing are just trying to hitch a ride on their bandwagon, same as their "Multi-Threaded Server" tries to hitch a ride on the Sybase bandwagon. : Anyway, thanks for the info. Too bad Informix hasn't caught on yet... : How sure are you? Is your Informix information more reliable than your Oracle : information?? :-) I'm sure it doesn't do versioning, or Oracle-like read-consistency. Informix offers you (ie the developer or query issuer) control over the level of isolation between: Dirty Read Committed Read Cursor Stability Repeatable Read Unlike ORACLE7, repeatable read is achievable without table-level locking (assuming appropriate indexing strategy) or read-only restrictions. Oracle claim that SELECT ... FOR UPDATE gives them Repeatable Read. I believe that their implementation does not prevent the insertion of a new row into the set, and therefore does not provide Repeatable Read. This flaw was not present in OnLine <= 5.01. I suspect (but have not yet verified) that it may be present in OnLine >= 6.00 due to the change from Adjacent Key Locking to Key Value Locking. In order to achieve Dirty Read type levels of performance ORACLE7 has to resort to kludges like Discrete Transactions (which break Oracle's Read Consistency Model). Most people consider this to be impractical in the real world. As most of my work tends to be performance oriented, I tend to lean towards favouring Dirty Read over Read Consistency (as do Informix, presumably). I do not recall anything other than MRP II where I saw Read-Consistency or Repeatable Read as a better tradeoff than Cursor Stability, but then it is many years since I was an application programmer! Don't get me wrong, ORACLE7 is a fine database. It's much easier to sell than Informix. It's just not as elegant nor as fast (and *I* believe that's cause and effect). -- graeme -- Disclaimer: The author's opinions are his own, and not necessarily those of Pyramid Technology Ltd. or Pyramid Technology Inc. --------------------------------------------------------------------------- -m------- Graeme Sargent Voice: +44 (0)252 373035 ---mmm----- Senior Database Consultant Fax : +44 (0)252 373135 -----mmmmm--- Pyramid Technology Ltd. Telex: Tell who??? -------mmmmmmm- Farnborough, Hants GU14 7PL Email: graeme@pyra.co.uk --------------------------------------------------------------------------- We have the technology. The tricky bit is learning how to use it.