Hey Stephen, Thanks for the reply..sorry for my late reply..
I'm not really seeing where this is taken into account in the code unless something is implied in some of the memcache calls (which as far as I can tell from the reference, isn't the case). I'm not seeing where the cache is reseeded with data from the Datastore when a counter value is dropped? As far as I can tell the sample code will work as long as the counter key isn't dropped from memcache..but if it is, as far as I can see your datastore counter will get reset. As far as I can tell, all that happens if a key isn't in memcache, it's added with a value of one. It doesn't ask the datastore if it has knowledge of the counter and retrieve the last stored value..it just adds the key again with a value of one. When that value gets flushed to the datastore later, it'll overwrite the old counter value. Sorry if this is blindingly obvious :| I'd appreciate any further explanation..cheers! :) On Jun 15, 4:17 pm, Stephen <sdea...@gmail.com> wrote: > On Jun 12, 2:19 pm, peterk <peter.ke...@gmail.com> wrote: > > > 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.... > > > (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). > > No, IIRC they take this into account. > > If the cache is flushed then the next call to increment will fail, > because the memcache API does not automatically start from zero when > incrementing a non-existing key. > > At this point you query the db to re-seed the cache, but there is > another potential race condition: you have to set the new value of the > cache such that if it already exists (another app instance > concurrently beat you to the update because it also noticed a missing > cache entry) you don't overwrite it. > > At this point the the cache has a value and you can retry the > increment call. > > So depending on cache flushing and concurrent activity, incrementing > the cache value can be up to a 3-step process. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
