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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
