List:Falcon Storage Engine« Previous MessageNext Message »
From:Ann W. Harrison Date:March 31 2009 2:49pm
Subject:Re: statement-level atomicity
View as plain text  
Kevin Lewis wrote:
 > Philip,
 > 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
are running.

 > 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
the latter.
 > 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?


statement-level atomicityKevin Lewis31 Mar
  • Re: statement-level atomicityAnn W. Harrison31 Mar
Re: statement-level atomicityPhilip Stoev31 Mar
  • Re: statement-level atomicityKevin Lewis31 Mar
  • Re: statement-level atomicityJim Starkey31 Mar
    • Re: statement-level atomicityAnn W. Harrison1 Apr