> From: Len Popp [mailto:[EMAIL PROTECTED] > 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 session.getAttribute > 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 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
