tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darryl L. Miles" <dar...@netbauds.net>
Subject Re: Tomcat/JVM hangs in session.getAttribute / HashMap.get()
Date Tue, 06 Sep 2005 16:07:21 GMT

It seems possible to be that one user simply pressing the reload button 
a few times quickly while the same page is not yet loaded can cause sync 
problems to his own session; and you can't control the user.

Err... does anybody have a replacement class for HttpServlet ?  A simple 
access wrapper class would only protect co-operative users of it, a 
replacement for HttpServlet would protect all users and persist across 
requests.

It seems like the general case needs to use one, while only performance 
optimized case would be able to make do with the current one.

While I agree developers should have access to low level classes to get 
raw performance, I don't agree that the normal case should expose such a 
basic design error.  HTTP is designed to specifically allow simultaneous 
requests to be processed at the same time.

With a replacement class for HttpServlet you'd be better of using a 
ReadWriteLock to protect access, which allows for threading of the 
common read access case.

Tut, tut.


Arup Vidyerthy wrote:

>I have been watching this thread with interest.
>
>Does this mean that all session.setAttribute() and session.getAttribute()
>should always be synchronised (for instance, inside a servlet or struts
>action) provided the same hashmap is accessed by say more than one
>servlet/struts action?
>  
>

-- 
Darryl L. Miles



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message