Basically you can't tell. Also you memcache capacity is finite so you by stuffing it with stuff in case you need it, will inevitably evict something else.
You basic design pattern needs to be Check in memcache if not their fetch from the datastore if you think the data will be re-used stick it in memcache Various scenarios may lend them selves to preloading the cache (but note the point at the top) If you can identity a users requirements specifically, when they log in you could fire of a task in the background which could pre-load the cache with stuff you think they will look at shortly, but you still have to deal with cache misses. I dont think running your own mechanism in the backend would be particularly useful unless you can guarantee a huge cache hit rate as it is a finite resource. Also think about how you can fetch the data from the datastore more efficiently. Getting data by key can be very fast. Given the client will only fetch the data once, and you don't know when they will do it keeping the data hot in memcache seems an expensive excercise, especially if you can optimize the data in the datastore for the client so they can fetch it with a single db.get() How are detecting the data change that triggers the notification? Just my 2c 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/-/QQMA5FBKJWMJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
