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 10:24:20 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 remm@apache.org  2005-09-08 12:23 -------
(In reply to comment #24)
> Hmm, I also thing the spec interpretation from the current
> StandardSession inside Tomcat 5.0 and 5.5. is wrong. We had the same problem
> at Cluster DeltaSession for year ago. We now sync also the session attribute 
> read operations. Without this fix the Cluster setup is useless for
> production servers. 
> 
> I vote for change the StandardSession implementation to..

Ok. I don't know yet, since the repository is inconclusive, and doesn't match
what you wrote. I see DeltaSession (introduced first along with 5.0.15+) has
always had (from revision 1.1) syncs on everything (read/writes), so I don't see
any conclusive information showing that the current 5.5.x code does produce the
bug described here. Obviously, if 5.5.x really is still bad for this issue,
it'll have to be fixed.

(In reply to comment #23)
> Remy, sorry, but you are wrong. The read is the problem, not the write. During
> the write process the hashmap is in flux, so if a read occurs at this time and
> is not synchronized the thread which reads is killed.
> So 5.5.x is as broken as 5.0.x is

This means you've tested with 5.5.x, and reproduced an issue ? Or written a
microbenchmark showing a problem with reads ? All I can see is that you're
saying "issue on read, 5.5.x same problem" like a broken record.

(In reply to comment #22)
> Apparently it is indeed a good thing :-).  The appropriate patch was just
> committed to the Glassfish repository.  If people want an open source
> implementation of the servlet spec where the developers listen to users on
> issues like this, you might want to browse over to:
> 
>     https://glassfish.dev.java.net
> 
> and take a look.

Lol, whatever. The web tier of Glassfish is really an ugly behind-the-back fork.
All that was required to avoid the ill feelings is a bit of respect, being
informed just a little bit, which would have allowed reasonable planning for
development resources. I'm glad you're happy about Glassfish, but personally,
I'll use it in the long run to point out there are problems with large companies
like Sun and IBM, their interactions with the ASF, and how they should not be
trusted (as in, accept whatever they contribute, but there's no need for being
thankful for it - and obviously, don't install them as "despot" on a project
ever, but at the ASF, it's a bit hard to get into this situation).

> This (removing my name from the @author tag on StandardSession), both here and
> everywhere else in the Tomcat code base, would indeed be my wish.

I wasn't really serious. In the end, it's not really my decision, so you should
send a request to the pmc once it is correctly setup.


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