tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joseph Morgan" <>
Subject RE: Uniqueness of a sessionId
Date Fri, 08 Jan 2010 14:47:29 GMT
So, can you setup a service in A to generate all session ids for all

-----Original Message-----
From: Arnab Ghosh [] 
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
more separate context which will reuse the context A. These other
will be very lightweight and will contain only one servlet and all
it will forward to appropriate URI of context A.

While dispatching request from other context say B to A , a new session
getting created and then it is setting the JESSIONID cookie in request.
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
available in context B.(created and then forwarded by another context
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.



On Fri, Jan 8, 2010 at 7:06 PM, Joseph Morgan
> 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
> of architecture, and not of Tomcat capabilities.
> I'm still not sure what you are doing, but it seems you want to be
> 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
> to set up a very small app with a single service that spits back
> id's.  However, if those session id's need to be persistent, a DB
> with a single autoincrement would suffice.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message