Hi Joshua, As robert said, making a process idempotent depends mostly on the app logic and data model. IMO for the example case you need more of a context of how the counter is been use to make the use of the counter in a transaction idempotent. (remember: the example just illustrates how to make use of a transaction, it does not handles any retry if the transaction failed or not)
As you said: making a separate child model, which is parent by the object you are transacting on, and inside the transaction query to see if its already in there, Its a good solution to make your transaction idempotent, and I don't see a problem why this approach wont scale. If you do an ancestor query on that kind it would be very fast. With this approach, the code inside the transaction should do something like: 1) read child entity 2) if entity not processed, do the transaction logic. else: no nothing. FYI GAE support transactions, because either the whole transaction succeeds or fails. Whether you know about the outcome or not is different. Although making process idempotent is somewhat a complicated logic, here the better solution would be to figure out why the exception is occurring. Mostly because this type of exception are not common. You don't need to "only" write idempotent transactions, you should make them idempotent, unless it does not matter if they succeed or not, as I said before this type of exception are not common so there are many cases where 100% data retention is not as important. On Thursday, July 28, 2011 7:02:53 AM UTC-7, Joshua Smith wrote: > > 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-a...@googlegroups.com. > To unsubscribe from this group, send email to > google-appengi...@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 view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/FgjOX6rQpu4J. 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.
