tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
Date Thu, 08 Sep 2005 14:58:59 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=36541>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36541





------- Additional Comments From andrewm@2sheds.de  2005-09-08 16:58 -------
(In reply to comment #38)
> I think the trouble without any sync could only occur if there was more than one
> concurrent unsynced write, and in particular, two "remove"), the pointer value
> will be corrected and the loop should exit. That's my interpretation looking at

If I understand this statement correctly -
You are saying that syncing the put and remove should be enough to stop the
infinite loop, and that this is why it was "FIXED" in 5.5.

If an example could be provided that an unsynced get can lead to an infinite loop,
would this change anything concerning the status of this problem?

A second question following on from this:

When would anyone want to use a "threadUnsafe" session set/getAttribute?

As we have seen, NOT syncing this causes hangs - so therefore developer
needs to do this (if he uses these methods). Wouldn't it make more sense to
just sync it further down in tomcat, as suggested here, rather than needing
to sync the whole method every single time you use this in your code?


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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


Mime
View raw message