On Oct 23, 11:54 am, "Dan Sanderson" <[EMAIL PROTECTED]> wrote: > On Wed, Oct 22, 2008 at 5:28 PM, Ian MacLarty <[EMAIL PROTECTED]>wrote: > ... > > > However the article > >http://code.google.com/appengine/articles/transaction_isolation.html > > gives the impression that the transaction isolation level is read > > committed. That would imply that another concurrent transaction > > *could* update the counter value after the get, but before the put > > (even inside a transaction). > > While an update to an entity group is in progress, the datastore bounces > other attempts to update the group. (The client retries several times > before giving up.) It does this during the entire transaction, so the > entity group will not change between the beginning of the transaction and > the end of the transaction. In the increment_counter example, this includes > the get() as well as the put(). The client knows which group to update > because it queues all datastore changes during the transaction code, then > executes them all at the end. >
Cool. Thanks for clarifying that. > The transaction isolation article is more about reads. Reads succeed even > while another client is performing an update. Up to the first milestone, > reads return the entity in the state prior to the update. After the first > milestone but before the second, reads return the entity in its new state, > but queries match the old state. After the second milestone, both reads and > queries use the new state. > Okay. > > Would someone mind clarifying this for me? Is the counter example > > above guaranteed to atomically update the counter if it succeeds? If > > that is the case, then I think the isolation level article is a bit > > misleading, because the isolation level would be closer to > > serializable. > > Are there a particular passages in the article that imply this? Maybe it > could be clarified in the text. > I think the problem has to do with the text "...the datastore's isolation level most closely resembles Read Committed.". In RDBMS speak a READ COMMITTED transaction may read changes committed by another concurrent transaction. If you were using a traditional RDBMS and you tried to increment a counter in a READ COMMITTED transaction by first querying the value of the counter and then updating it, you might get data skew, because another transaction could commit after the select, but before the update. >From your description I'd say that transactions in the GAE datastore are closer to SERIALIZABLE. I think it's important to emphasise that an entity group cannot change during a transaction and that any transactions that update the entity group will be effectively serialized (as I understand it). Someone coming from a RDBMS background who read the article may get the false impression that values can in fact change during a transaction since that is what is generally implied by READ COMMITTED isolation. That was the impression I got after reading the article. I'm very glad that's not the case. Cheers, Ian. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
