I have changed the offending sentence to
"Under REPEATABLE READ and READ COMMITTED, a SELECT statement may return
"can't find record" if the table has changed while the query was in
In other words, it now describes the observation without trying to explain
it. I hope this is acceptable to you.
With respect to the core issue and whether it is a violation of ACID, I will
leave it for you guys to decide. I personally think that it is more than a
nuisance, because for longer-running SLEECTs it is possible that the SELECT
will never complete regardless of how many times you reissue it.
Please let me know if you need anything else from me.
----- Original Message -----
From: "Kevin Lewis" <Kevin.Lewis@stripped>
To: "Philip Stoev" <pstoev@stripped>
Cc: "Rune Humborstad" <Rune.Humborstad@stripped>; "Ann W. Harrison"
<Ann.Harrison@stripped>; "FalconDev" <falcon@stripped>
Sent: Tuesday, March 31, 2009 5:27 PM
Subject: statement-level atomicity
> Could you add a reference to
> about what you mean by 'statement-level atomicity'? I think that you may
> be using a broader definition that is necessary.
> In my view the only thing required is that all changes within a SQL
> statement either commit together or none at all. No client should ever
> see part of a change and not the rest.
> But I think you are suggesting in this report that SQL statements must
> always act on the database as if there were no other changes happening at
> the same time. Certainly, READ COMMITTED transactions cannot act this
> way. They pick up changes from others in the middle, and if a record it
> had read but not locked gets deleted, "can't find record" errors WILL
> It may be argued that "can't find record" errors are a nuisance during
> REPEATABLE READ transactions, but I am not sure they indicate a failure of
> statement-level atomicity.