hey david! wow, comprehensive. you're right: modulo some minor implementation details, this is basically our optimistic concurrency algorithm.
your concern stems from the fact that the datastore doesn't use locks, so txes aren't really ordered like they are in lock-based systems. in a lock-based system, regardless of whether the locks or simple or differentiate btw reads and write, T2 wouldn't start until T1 has committed. given that, yes, T2 would see T1's write. in our datastore, however, you're right, T2 can run concurrently with T1. T2 issues its reads before T1 commits, so to preserve isolation, T2 isn't allowed to see T1's in progress tx. if was, it might see inconsistent data. to make this concrete, let's say T1 is transferring $1 from account A to B, and T2 is reading the balances of A and B. if T2 could see T1's in-progress writes, this could happen: - T1 adds $10 to B - T2 reads A and B - T1 deducts $10 from A if T2 sees B's balance after T1 adds $10 to it, T2 will see that B has $10 extra, but A still has the same amount. (it doesn't matter if T1 deducts from A first. T2 would see a similar inconsistency.) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
