So, can you setup a service in A to generate all session ids for all contexts?
-----Original Message----- From: Arnab Ghosh [mailto:gh...@glenwoodsystems.com] Sent: Friday, January 08, 2010 8:15 AM To: Tomcat Users List Subject: Re: Uniqueness of a sessionId Dear Joseph, Actually I am working on a cross-context application. There is one main application say A . It is a very big application . Now I want to create some more separate context which will reuse the context A. These other context will be very lightweight and will contain only one servlet and all request it will forward to appropriate URI of context A. While dispatching request from other context say B to A , a new session is getting created and then it is setting the JESSIONID cookie in request. Then it is forwarding the request to context B. Context B is checking the JESSIONID and creating a new session with the existing cookie. Now in this scenario, it may happen a session with that sessionId is already available in context B.(created and then forwarded by another context say C). In that case it will start using that session. So that's why I want a unique active sessionId set to maintain uniqueness of each session in context B. Thanks, Ghosh Now On Fri, Jan 8, 2010 at 7:06 PM, Joseph Morgan <joseph.mor...@ignitesales.com > wrote: > Arnab, > > I've been silently following your thread (mainly because I'm not even > remotely as smart as the folks out here), but it seems you have an issue > of architecture, and not of Tomcat capabilities. > > I'm still not sure what you are doing, but it seems you want to be able > to pass (and cache as a session) data between instances. Many do this > with either a DB or a messaging system (which is essentially a DB app > with correlation abilities). > > If you simply need unique IDs across contexts, you should think about > setting up a service to issue those IDs. A quick hack on that would be > to set up a very small app with a single service that spits back session > id's. However, if those session id's need to be persistent, a DB table > with a single autoincrement would suffice. > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
