"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
