Hi It won't ever be a true singleton as each instance running would have a copy in their memory. If the entity is predominately read only, then it doesn't really matter if their state is retrieved from the datastore or from memcache when you need it. Its probably more like a borg than a singleton. The idea of the borg pattern is you can create as many copies you like but all share the same state.
See http://www.aleax.it/Python/5ep.html and http://code.activestate.com/recipes/66531/ The main problem will be if you start updating it/them all over the place then you need to ensure everyone is invalidating their copy. Which should mean you at least reload it on every request, which in the main would guard against any real problems with shared state getting out of date. Rgds Tim On Jul 26, 9:45 am, Shane <shanelstev...@gmail.com> wrote: > Hi, > > I am intrigued as to how singletons work in Google App Engine. Given > your application can be running in multiple processes (on multiple > machines) at once, and requests can get routed all off the place, what > actually happens under the hood when an app does something like: > 'CacheManager.getInstance()'? > > I'm just using the CacheManager as an example, but my point is, there > is a single global application instance of a singleton somewhere, so > where does it live? Is an RPC invoked? In fact, how is global > application state (like sessions) actually handled generally? > > Regards, > Shane --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
