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
-~----------~----~----~----~------~----~------~--~---
