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