tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arnab Ghosh <gh...@glenwoodsystems.com>
Subject Re: Uniqueness of a sessionId
Date Fri, 08 Jan 2010 14:15:20 GMT
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.morgan@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.
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message