I agree with Barry. instance level caching should really be kept for data that won't change for the life of the instance. ie static data that will only be changed with a new deployment. due to all the issues of cache invalidation.
However there is one other level of cache often overlooked and that is request level caching. (not sure how that can be performed in java :-) If you have entities that your code base may refer to multiple times during the life of the request, then caching these entities at the request level can be a big win. the cache layers then look like datastore -> memcache -> request cache applicability obviously depends on the use case. Cheers Tim On Monday, March 17, 2014 8:56:12 PM UTC+8, barryhunter wrote: > > You could perhaps do it in a very crude fashion using traffic splitting. > > https://developers.google.com/appengine/docs/adminconsole/trafficsplitting > > ie users can be directed to a consistent(ish) version. And each version > has its own instances. > > > But you can't stop each version spawning multiple instances, and hence > invalidating and instance cache. > > > As noted, use Memcache! > > > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@googlegroups.com. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/d/optout.
