Hey all.. Just wondering if I picked this up wrong or if this would indeed need some changing. Looking at the counter example in this presentation:
http://code.google.com/events/io/sessions/OfflineProcessingAppEngine.html (From slide 37 in the PDF) Basically, is this example not depending on cache being persistent in order to work? You're incrementing the counter in cache, then periodically persisting it to the DB, but if the cache drops your counter here, you're basically going to reset your counter (and thus reset the counter in the DB on the next queued update). For a real world counter would you not need to basically write the changes to the counter individually to cache (e.g. 'counter_x +1','counter_x+1'..), then aggregate these changes in your task handler and add the result to the counter in the DB? A small thing..but bugging me in case I'm missing something :) I wasn't at IO, just watching the presentations now, and I'm seriously enthused by what this all might mean for write costs..there are apps in my head with high write rates and that would benefit from 'aggregate, then write', and this could make things a lot easier. Awesome stuff appengine team! :) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
