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 <[email protected]>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) > <[email protected]<ikai.l%[email protected]> > > 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 <[email protected]>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 >>> [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]<google-appengine-java%[email protected]> >>> . >>> 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 >> [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<google-appengine-java%[email protected]> >> . >> 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 > [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-appengine-java%[email protected]> > . > 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 [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-java?hl=en.
