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. The only operation happening
in the example transaction is an update (a read, modification, and
write of the same entity). 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.
Ross Ridge
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
