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

Thanks for the edit.  I agree that for a SELECT statement, a concurrent 
change should not cause a 'Can't find record' error.  With 
READ_COMMITTED the missing record should be ignored, and for 
REPEATABLE-READ, Falcon should still have a copy of the deleted record 
that existed when the transaction started.  UPDATE & DELETE statements, 
however, are less clear.


Philip Stoev wrote:
> Kevin,
> 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 
> progress."
> 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