tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
Date Wed, 07 Sep 2005 22:41:07 GMT wrote:
> ------- Additional Comments From  2005-09-07 21:29 -------
> After we finish clarifying who's is bigger (and mine is best case average), we
> could return to the bug.
> 1. The bug isn't invalid, so I reopen it. You can set it to WONTFIX, but not to

Indeed, WONTFIX looks to me like a reasonable resolution.

> 2. Applications working well with tomcat 4, resin or probably any other servlet
> container do not work with tomcat 5.0.x or tomcat 5.5.x. Thus tomcat 5 seems to
> be not compatible to the servlet spec (or be the only one compatible), if not in
> the language of the specification itself, but in the intension of it. So tomcat
> 5 can be considered BROKEN.

Fine with me.

> 3. The bug applies to tomcat 5.5.x as well, because 
> "... added back synchrnozation on write operations to the map in the 5.5
> branch... " doesn't fix anything, since the read operation are the problem and
> MUST be synchronized. 

Well, actually, I think you should bring that up with Sun, which have 
made a questionable/unsafe implementation of the collection IMO.

A reasonable fix I would consider, however (showing I am not saying "no" 
to your bug report just for fun), is using another collection 
implementation, or tweaking that one, whatever works. After all, all 
that is missing is something like an e != in HashMap.get.

But of course, we're the OSS project, so we're always the ones being 
bugged to death, rather than proprietary software vendors :(

Synchronizing the writes will also fix problems, since I think the 
underlying structure of the hashmap went bad due to a concurrency of 
reads. Try it before whining. Thanks.

> 5. The idea of removing synchronization to gain performance is absurd.
> Who needs the performance? People like us, who have 2000-3000 concurrent users
> on each webserver. But people who have 2000-3000 concurrent users, have also
> many concurrent requests, even from the same user, so instead of gaining
> performance we are gaining CRASHES. This bug killed 8 (!!!) webservers yesterday. 

I have extremely few problems with this.

> 6. Consider the flurry in the tomcat users community, if the above points + your
>  refusal to provide a three LOCs fix gonna make tomcat 5 UNUSEABLE.

Funny. The only flurry is the one you have created, and that I will have 
to ignore.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message