List:Falcon Storage Engine« Previous MessageNext Message »
From:Jim Starkey Date:March 31 2009 6:50pm
Subject:Re: statement-level atomicity
View as plain text  
"Repeatable read" and "read committed", definition, are not consistent 
and not isolated, so, no, they aren't ACID.


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
>>
>> https://inside.mysql.com/wiki/SEIdependantTestSuiteTransSummary
>>
>> 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
>>
>>
>>
>>
>
>


-- 
Jim Starkey
President, NimbusDB, Inc.
978 526-1376

Thread
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