Yeah, that would have been a design flaw, definitely :-) The fear I had was when seeing a static methods being used. I'm always afraid when I see 'static' somewhere.
For Gaelyk (http://gaelyk.appspot.com/tutorial#namespace), I've added a method to "wrap" the usage of a namespace under a certain scope. An example is better than my crappy explanation, what I meant is this: // temporarily set a new namespace namespace.of("customerA") { // use whatever service leveraging the namespace support // like the datastore or memcache } // once the closure is executed, the old namespace is restored That way, I can deal with setting a temporary namespace for a customer, for a limited scope (like admin data could be in their own namespace, etc). But of course, the approach of using filters is great for various scenarios, and it's transparent for the servlets down the filter chain. Anyhow, thanks a lot for lifting the doubt about the thread-local usage :-) Guillaume On Wed, Sep 15, 2010 at 23:48, Ikai Lan (Google) <ikai.l+gro...@google.com<ikai.l%2bgro...@google.com> > wrote: > Yes, it should be thread local. That'd be a pretty bad design flaw if it > wasn't! The reason you may have thought it wasn't is because the Python > implementation isn't - but that's a non issue since Python app servers are > single threaded in production. > > On Wed, Sep 15, 2010 at 9:24 PM, Guillaume Laforge <glafo...@gmail.com>wrote: > >> Out of curiosity, the namespace info is stored in a thread-local? >> So I can have two concurrent requests (from, say, two different customers) >> using a different namespace? >> >> The fact of doing NamespaceManager.set() with a static method is quite >> frightening as it could be thought of as being done globally to the whole >> application. >> But I suspect this is not the case, hopefully :-) >> >> Guillaume >> >> On Wed, Sep 15, 2010 at 23:14, Ikai Lan (Google) < >> ikai.l+gro...@google.com <ikai.l%2bgro...@google.com>> wrote: >> >>> Why not just do this with a servlet filter? It's very cheap to do and >>> isnt't computationally expensive - it's not like you're reestablishing an >>> expensive connection or anything. >>> >>> >>> On Wed, Sep 15, 2010 at 12:08 PM, Vikas Hazrati <vhazr...@gmail.com>wrote: >>> >>>> We are building a multi-tenant application and want to use the >>>> NamespaceManager to distinguish between tenants on the basis of server- >>>> name. So for example inphina.bookmyhours.com would be a different >>>> tenant than te-con.bookmyhours.com >>>> >>>> we are currently using NamespaceFilter with code similar to >>>> >>>> if (NamespaceManager.get() == null) { >>>> switch (strategy) { >>>> case SERVER_NAME: { >>>> logger.info("The namespace for the >>>> request is: " + >>>> request.getServerName()); >>>> >>>> NamespaceManager.set(request.getServerName()); >>>> if(seedDataSetup.setSeedData()) { >>>> >>>> adminAccountValidator.updateAdminPassword(); >>>> } >>>> break; >>>> } >>>> >>>> What we observed is that we always fall into the condition of >>>> NamespaceManager.get() == null and hence the code has to set >>>> NamespaceManager.set(request.getServerName()); again. Is it possible >>>> to retain this setting at a session level. For all our users logging >>>> in from inphina.bookmyhours.com, they would remain to be within the >>>> same tenant. >>>> >>>> From the current implementation, it looks like the NamespaceManager >>>> has a request scope. Comments/Suggestions? >>>> >>>> Regards | Vikas >>>> www.inphina.com >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Google App Engine for Java" group. >>>> To post to this group, send email to >>>> google-appengine-j...@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> google-appengine-java+unsubscr...@googlegroups.com<google-appengine-java%2bunsubscr...@googlegroups.com> >>>> . >>>> For more options, visit this group at >>>> http://groups.google.com/group/google-appengine-java?hl=en. >>>> >>>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Google App Engine for Java" group. >>> To post to this group, send email to >>> google-appengine-j...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> google-appengine-java+unsubscr...@googlegroups.com<google-appengine-java%2bunsubscr...@googlegroups.com> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/google-appengine-java?hl=en. >>> >> >> >> >> -- >> Guillaume Laforge >> Groovy Project Manager >> Head of Groovy Development at SpringSource >> http://www.springsource.com/g2one >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google App Engine for Java" group. >> To post to this group, send email to >> google-appengine-j...@googlegroups.com. >> To unsubscribe from this group, send email to >> google-appengine-java+unsubscr...@googlegroups.com<google-appengine-java%2bunsubscr...@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/google-appengine-java?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine for Java" group. > To post to this group, send email to > google-appengine-j...@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine-java+unsubscr...@googlegroups.com<google-appengine-java%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine-java?hl=en. > -- Guillaume Laforge Groovy Project Manager Head of Groovy Development at SpringSource http://www.springsource.com/g2one -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to google-appengine-j...@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
