The problem is that google transactions can report an exception, and then go ahead and succeed anyway.
So the docs recommend that you only write idempotent transactions, which is a completely silly suggestion. I've yet to see a single example of how one might write an idempotent transaction. (Unless, I suppose, you create a separate child model in the database which is parented by the object you are transacting on, and then you query the list of children every time you retry your transaction to see if its already in there, but that won't scale.) I contend that a DB that cannot tell you reliably whether a transaction succeeded for failed does not support transactions. GAE can essentially report 3 possible results from a transaction: - Definitely succeeded - Definitely failed - Beats me I contend that third possible result makes it impossible to write software that relies on transactions. Therefore, GAE doesn't support transactions. On Jul 27, 2011, at 8:58 PM, Tim Hoffman wrote: > If you always get modify put within a transaction how would it be unreliable? > > Rgds > > Tim > > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/google-appengine/-/mP_8kv_-LlMJ. > To post to this group, send email to google-appengine@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. -- 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 google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
