tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Caldarale, Charles R" <>
Subject RE: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
Date Thu, 08 Sep 2005 03:50:42 GMT
> 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:

View raw message