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