Hi Scott, > > It seems that in the code it writes out a task in a queue to close the > commits, possibly. I'm pretty sure transactions should not be > implemented using queues, for any reason. The complexity of storing > temporary lock/tx objects in the datastore, time spent during that > transaction, and then pushing them through with a task (maybe much > later) seems like a dangerous plan. > As you know, "Eventually Consistent" is a very important concept for scaling applications. To enable "Eventually Consistent", Transactional Task Queue is a key item.
See "BASE: An Acid Alternative": http://queue.acm.org/detail.cfm?id=1394128 > Supporting multi-entity-group transactions needs to be implemented at > the datastore and not in a wrapper like that, IMO. There is no way to > rollback any committed transactions from any other entity-group, and > there are many other issues as well ... there is too much application > specific behavior that can't be assumed. > If you start committing a global transaction, you cannot cancel it as well as com.google.appengine.api.datastore.Transaction. If you do not commit a global transaction, you can cancel it freely. > > What happens if you have 3 transactions (1 transaction over 3 entity > groups) and the first two entity group transactions commit and the > third fails during commit? Is there a way to roll the first two back? > Slim3 locks an entity group when getting, putting and deleting entities so that nobody updates the entity group. So it never happens that the first two entity group transactions commit and the third fails. > What happens if your user expect transactions to work like a database > where you have transaction isolation with gets/queries and updated the > value of the same entity multiple times from repeated gets? (think of > multiple "get, incr. object property, put" where the object only gets > incremented by the last amount, not the sum of the increments) > Unlike with most databases, queries and gets inside a datastore transaction do not see the results of previous writes inside that transaction. Specifically, if an entity is modified or deleted within a transaction, a query or get will return the original version of the entity as of the beginning of the transaction, or nothing if the entity did not exist then. http://code.google.com/appengine/docs/java/datastore/transactions.html#Isolation_and_Consistency > Where does the user get an error if the transaction fails later when > the task runs from the queue? (sure, that is application specific, but > dangerous all the same as the current models don't allow for implicit > non-synchronous operations). > As described the above, if the task runs, the global transaction never fails. Thanks, Yasuo Higa -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
