Hi Pat, I already implemented that approach and it works quite well. Basically I used a session state wrapper that prefixed the state keys with some virtual app key. Unfortunately it means you can not use third-party components out-of-the-box that access the session, too, and are unaware of that fact. I would prefer having a "context per virtual app" if it's affordable in matters of memory. also, being able to control the settings of your app via your webserver and it's tools (domain mapping, restart, etc.) is quite comfortable and saves writing custom solution.
However, if everything breaks, it's still a solution to multiplex the session. best regards Peter P.S.: thanks again for the hibernate tip with keeping dao and session together :-) -----Ursprüngliche Nachricht----- Von: Patrick Casey [mailto:[EMAIL PROTECTED] Gesendet: Samstag, 8. Oktober 2005 18:08 An: 'Tapestry users' Betreff: RE: best strategy for keeping a huge number of web application contexts Peter, Did you consider just virtualizing within a single context? E.g. have your login screen ask: Name, Password, Instance? And then have multiple parallel instances running within the same context? That way you can share static data, cache, and whatnot between instances and, of course, still be backed by one and only one physical context. The only trick is you need to design your app in such a way that there are clean pinch points to introduce the instance level segmentation. I force all my DB queries, for example, to go through the same query resolver so that I can easily append "and instance="foo" to any instance-aware queries. I've worked on a *very* large corporate app that used this kind of segmentation and it worked quite well once we got the kinks out of it. It's not an easy task to tackle (because it requires touching a lot of parts of your code), but once you get it solved it opens a whole new world of application possibilities. --- Pat > -----Original Message----- > From: Peter Ertl [mailto:[EMAIL PROTECTED] > Sent: Saturday, October 08, 2005 4:08 AM > To: [email protected] > Subject: best strategy for keeping a huge number of web application > contexts > > Excuse for maybe being a little off-topic... > > In my tapestry app users can register for a test version of my > application. whenever this happens I have to register a new web > application context in the web server > ('/user4711' or so). > however the number of registered web contexts can be really(!) high > (+1000 > or so). > > I am really concerned about memory consumption (and cannot afford a > root server with 10+ gigabytes :-) > > java.lang.OutOfMemoryError really sucks as you now... > > right now i add a context.xml in tomcat pointing to the similar war > file (app.war). the referenced libraries from app.war are all located > in %TOMCAT_HOME%/share/lib (commons-logging, tapestry, hivemind, > hibernate, etc.). but still I have the impression that just having the > context already eats > up a few megabytes in tomcat. > > does somebody have practical experience on that? is jetty better for > that? is this setup considered to be robust? > > any help greatly appreciated!!!! > > Best regards > Peter > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
