tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arup Vidyerthy" <>
Subject RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
Date Thu, 08 Sep 2005 07:45:28 GMT

I use a synchronised HashMap like Chuck is suggesting here and I have to say
it's absolutely fine. We have an application here with hundreds of users
logging in and doing stuff concurrently and I have seen no negative impact
on performance. So basically you either do that or use something like a


-----Original Message-----
From: Caldarale, Charles R [] 
Sent: 08 September 2005 04:51
To: Tomcat Users List
Subject: RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get()

> From: Len Popp []
> Subject: Re: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
> Inside Tomcat, references to the hashmap in question are synchronized 
> on the hashmap object itself, StandardSession.attributes (see 
> org.apache.catalina.session.StandardSession).

Except it doesn't appear to be done consistently.  The existing
synchronization in 5.5.9 protects against concurrent updates, but not
against a retrieval that happens at the same time as an update.

I don't understand the rationale behind this "experiment" that removed the
synchronization, since uncontended object locking has very little
performance impact in modern JVM/JIT implementations.  Removal of the synchs
would allow concurrent retrievals, but would the frequency of that warrant
the reduction in robustness?

> So if I want to *safely* call session.setAttribute or
> I have to make sure the calls are synchronized on session.attributes.

Actually no - if you can find _all_ the events that can trigger references
or udpates to session attributes, you can synchronize on any object you
like.  The synchronize blocks internal to Tomcat then become redundant, but
they cause no harm.

Another option (as suggested by the HashMap javadoc) is to modify
StandardSession to use a HashMap wrappered by Collections.synchronizedMap().
No idea what kind of performance impact that would have, but at least it
would limit the changes needed to just one place in one file.

 - Chuck

MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.

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

Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail

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

View raw message