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 Fri, 09 Sep 2005 05:35:37 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 mario@ops.co.at  2005-09-09 07:35 -------
Too much has said alread, but I also think it is not the only option to simply
synchronize.

Most of the time the different webapps/technologies do not utilize the same
content of such a session map. e.g. JSF and your home app mostly wont use the
same keys in this hashmap.
So why introduce a bottleneck? (and I didnt mean a real performance one, its
more  philosophical)
Why should one technique influence another one? And there is an impact, in the
worst case this synchronized map acts like a "sequencer".

What I would like to say is, its somehow reasonable to not simply synchronize,
but to find a hashmap which is able to handle this case.

This hashmap should be able to insert keys in concurrent. I one insert the same
key in parallel the result wont be deterministic, ok - fine.
And for sure, such a map should not lock (and not even wait for some "free me"
event) on get.

Isnt there a "cool" java collection developer here?

-- 
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