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 occur.
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.