From: Kevin Lewis Date: March 31 2009 2:49pm Subject: Re: statement-level atomicity List-Archive: http://lists.mysql.com/falcon/653 Message-Id: <49D22D6C.9060208@sun.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT 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" > To: "Philip Stoev" > Cc: "Rune Humborstad" ; "Ann W. Harrison" > ; "FalconDev" > 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 >> >> >> >> > >