List:Falcon Storage Engine« Previous MessageNext Message »
From:Philip Stoev Date:March 31 2009 2:38pm
Subject:Re: statement-level atomicity
View as plain text  

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.

Thank you.

Philip Stoev

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

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

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