Re: Is This Behavior Documented?
In article <52ieo0$kdv@ultra.sonic.net>, "M. Livenspargar"
<michaell@sonic.net> writes
>And if so, where??
>
>I have a table with one column of datatype serial. The table has 2
>rows when I execute the following SQL in DBAccess:
>
>set isolation to committed read;>begin work;
>insert into table1 values (0);
>select count(*) from table1;>rollback work;
>
>
>The 'select count(*)' line returns a value of 3. After this code has
>executed, a 'select count(*)' returns a value of 2, just as I would
>expect.
>
>Why does the select in the code given return a value of 3 when the
>isolation level is set to committed read and there are two committed
>rows and one uncommitted row? I assume it is because the same process
>that issued the insert is doing the select. Is this an
>implementation-dependent feature, a rule, or a bug? I'm running
>v7.11.x of the engine.
>
>Thanks for your help,
>M. Livenspargar
>
>
Seems to be an implementation dependent feature. I have seen code like
# Process y's
...
UPDATE x set y = 1 where z=2
INSERT into .. values(y).
...
...
# Process q's
UPDATE x set q=1 where z=2
INSERT into ... values(q).
Clearly the second update has to see the version of the row(s) which
have been updated by the first update. Odd code but is does seperate
out processing of y's and q's. Handly when you have lots of 'links'
to update on one table in one transaction.
--
David Williams