Re: Single-statement 'write consistency' on read committed. Oh, really?

andrew.clarke_at_logicacmg.com (APC) wrote in message news:<58428d02.0312020310.57fea9ae_at_posting.google.com>...
> tengizk_at_Hotmail.com (Tengiz Kharatishvili) wrote in message news:<3fcc40e7.0312010112.4ffa7d46_at_posting.google.com>...
> Really? Tom Kyte censored your posting? I must admit, I am shocked.
>

I wouldn't call it 'censorship' - they never promised to publish every single question they get. Which makes perfect sense, otherwise Tom's site could be flooded with trivial/recurring stuff. So, according to the openly published policy they pre-select questions based on how interesting the question and the answer would be for the public.

Obviously, they didn't find my original post and the following answers worth publishing. And I can understand why – for the vast majority of the Oracle developers there is no issue at all. It really takes a focused conscious effort to come up with somewhat exotic yet perfectly valid scenario that shows certain isolation anomalies (permitted by ANSI read committed anyway).  

> However, I think the behaviour you describe may no longer be an issue.
> …
> This morning, having followed Mark Powell's link to here I tried it
> again, this time on Oracle 9.2 for Windows but I could not reproduce
> the results. On this install adding "and pending <> 0" does not
> change the resultset: Session 2 still only updates _two_ rows.
>

Thanks, that's good to know that there's one less issue – this certainly makes it slightly more predictable.

> So, this looks to me to be either a fixed bug (incidentally, why did
> you say you thought Oracle didn't want to fix it, "for non-technical
> reasons"?) or it's one of those funnies we need to add to our new
> installation testing framework.
>

Well, sorry if it appeared confusing, but let me rephrase the bit about 'not fixing it for non-technical reasons': the real fix on my opinion would be either better documented restart on conflicts behavior [fix the docs] or making sure that any single-statement (with no sub-queries) read committed transaction always produces consistent results [fix the update conflict handling code].

But the truth is that fixing the code might in fact cause more problems – there's hundreds of thousands already written applications (including critical and important benchmarks) that might perform slower because of more restarts-behind-the-scene on write conflicts (let alone the fact that some unfortunate poorly designed apps might even produce incorrect results.)

Would it be a clear win? Sure, it would make purists like myself happier, but Oracle has more concerns than that. So, I believe that they simply act cautiously and responsibly – that's why I said 'non-technical' reasons. But on 'technical' side - they know precisely what to do and how to fix it – Oracle has a world class dev team.

However, as I said before - I would love them to document the current behavior better. Received on Tue Dec 02 2003 - 17:28:22 CST