tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Van Klaveren <>
Subject Re: Tomcat creating new sessions between Servlet->JSP request dispatch under load
Date Wed, 27 Apr 2005 14:32:00 GMT

Close, but it's more like this:

1 client (user)  == 1 session.

In most cases your client (assuming it's a browser) would only send
one request, which would translate into one thread, and therefor you
wouldn't have a threading issue with your Session object.  There is no
guarantee that your users won't either open up multiple browsers and
hit your application or, more realistically, they hit the submit
button twice therefor generating multiple requests to the server.  In
this situation it is conceivable that there could be a contention
between the two threads and the Session object.

This might sound far fetched but I've experienced this problem first
hand.  In general, you should only place objects in session if you
need to access it over several requests and you can't or don't want to
retrieve it from persistent storage.  If the data is meant for a
single request, place your object in request scope and forward to your
view component.

You mentioned that your problem got worse when you increased the
number of requests to the application.  This makes sense depending on
how you are generating the requests.  If you are using a tool that is
session aware then you are creating multiple threads that are all
trying to use the same Session object.

BTW, I copied this reply to the Tomcat Users List because I think this
is an important issue that a lot of developers don't
understand/realize.  I hope that's OK with you.

On 4/26/05, Riyad Kalla <> wrote:
> Andre,
> I appreciate the reply, something you said perked my interesting. You
> mentioned synchronizing on the session object, but as I understand it:
> 1 session == 1 thread == 1 client
> in Tomcat (or most typical application servers). So each client will
> have their own thread and session object, I don't need to synchronize
> on it (as I understand) because no two threads will ever be contenting
> with eachother for access to it.
> These are the facts that I have learned up until now, but if they are
> wrong please let me know, this is a pretty big oversight if indeed it
> is on my part.
> Best,
> Riyad
> On 4/26/05, Andre Van Klaveren <> wrote:
> > Riyad,
> >
> > You should not be using the Session object to store your DTO for
> > display.  Especially if you are forwarding the request to a JSP.  The
> > Session object should only be used to store data that is required to
> > remain in server memory between client requests.  I would place your
> > DTO in the Request object instead.  That alone will probably solve
> > your problem.
> >
> > Now, assuming you continue to use the Session object, you should
> > synchronize on the Session object before attempting to add your DTO
> > object to it.  That will prevent multiple requests from stepping on
> > each other while trying to add their DTOs to the Session.
> >
> > I haven't looked at Tomcat's code to see how they implemented the
> > hashCode method of the Session object but it's not the best way to
> > determine if two Sessions are equal in your case.  The hash code may
> > depend on the contents of the Session object.  I would print out the
> > session ID instead.  This will truely tell you if you have two
> > different sessions.  From what you describe I find it hard to beleive
> > that you there is a second session creeping into the picture within
> > the same request.
> >
> > --
> > Virtually,
> > Andre Van Klaveren
> > SCP
> >

Andre Van Klaveren
Architect III, SCP
Enterprise Transformation Services
Unisys Corporation

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

View raw message