Kevin Lewis wrote:
> 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.
Statement level atomicity is (or at least was a few years ago when
I was following it) a controversial issue in the SQL Standards world.
The standard itself is not explicit. Several commentators (Bernstein
and Date among them) are adamant that a statement should not see
concurrent changes, but as far as I know, that language is present
in their books, but not in the standard.
> 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.
That much is absolutely clear for repeatable read. READ COMMITTED
transactions can see part of an update if it is committed while they
> 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 occur.
But do we need to report it, or is the disappearance of a record a
normal part of the actions of a READ COMMITTED transaction. I favor
> 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.
Do you mean REPEATABLE READ here? I think we should get those errors
in repeatable read only if we've got consistency off and are doing a
select for update. And even then, just suppress them. The record's
gone. So what?