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

[EMAIL PROTECTED] (APC) wrote in message news:<[EMAIL PROTECTED]>...
> [EMAIL PROTECTED] (Tengiz Kharatishvili) wrote in message news:<[EMAIL PROTECTED]>...
> 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.