On Oct 24, 2:09 am, Ross Ridge <[EMAIL PROTECTED]> wrote: > Ian MacLarty wrote: > > 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. > > There's no SELECT in the example in the documentation as queries > aren't allowed inside of a transaction.
There is a call to db.get. This would be analogous to a SELECT in a relational database. Instead of SELECTs and UPDATEs maybe it'd be better to talk about atomic reads and writes. In a relational database the following sequence of atomic reads and writes in a READ COMMITTED transaction wouldn't work: read counter write counter + 1 To make it work you'd either have to use a SERIALIZABLE transaction or use an atomic update, such as: UPDATE counter_table SET counter = counter + 1 > The only operation happening > in the example transaction is an update (a read, modification, and > write of the same entity). The documentation gives the impression that the read and write are separate operations, because it says that without a transaction another process could update the entity between the get and put. If the get and put are merged into one atomic operation because they are inside a transaction, then that means the transaction is SERIALIZABLE. > Since any query that might have found the > entity being updated has to run outside of the transaction it's > possible the for entity to be changed in between the time it's > selected and updated in the transaction. > So in that way it's similar > to the read comitted isolation level of relational databases. > I'm sorry if I confused the issue by using the term "query" when I meant "atomic read using a key" or "get". I meant "query" in the relational database sense (i.e. a read), not in the GAE datastore sense. The *transaction* isolation level is all about how concurrent *transactions* interact. Since queries that use indexes are not allowed inside a transaction, the whole discussion about queries that use indexes is irrelevant to a discussion of *transaction* isolation level. My main point is that, because of the restrictions and semantics of datastore *transactions*, the illusion is created that all datastore *transactions* are executed sequentially, one after the other, in some unspecified order. By definition this means that the *transaction* isolation level is SERIALIZABLE. Operations that cannot be executed inside transactions (such as queries that use indexes) are not affected by the *transaction* isolation level. Here are some relevant quotes from the SQL 99 standard that defines the different transactions isolation levels: " The isolation level of an SQL-transaction defines the degree to which the operations on SQL-data or schemas in that SQL-transaction are affected by the effects of and can affect operations on SQL-data or schemas in concurrent SQL-transactions. " " The highest isolation level SERIALIZABLE, guarantees serializable execution, meaning that the effect of SQL-transactions that overlap in time is the same as the effect they would have had, had they not overlapped in time. The other levels of isolation, REPEATABLE READ, READ UNCOMMITTED and READ COMMITTED, guarantee progressively lower degrees of isolation. " The article "Transaction Isolation in App Engine" quotes wikipedia's definition of transaction isolation level. The quote is misleading, because it doesn't mention transactions at all, only "operations". The rest of the wikipedia article discusses isolation levels in terms of transactions. I think maybe what the article should say is something like: Datastore *transactions* are SERIALIZABLE, however certain operations, such as queries that use indexes, are not allowed inside datastore transactions. For these operations isolation is similar to READ COMMITTED and works as follows... Saying "the datastore's isolation level most closely resembles Read Committed" is simply misleading and does GAE a disservice IMHO. Thanks very much for your replies. 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 google-appengine@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
