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 16:17:44 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 hwadechandler-apache@yahoo.com  2005-09-08 18:17 -------
(In reply to comment #48)
> (In reply to comment #47)
> > I guess the point of the above would be that desired synchronization behaviour 
> > is usage-dependent, so giving the developer the freedom/responsibility to 
> > decide it is not necessarily a bad thing. Personally my reading of the spec 
> > was that this was the reason it was left to the developer: because only the 
> > developer has a good idea what the desired sync behaviour is.
> > 
> 
> It would be fine if all the other places in Tomcat were fixed to allow you to do
> that.  Point in case jsp:useBean with scope="session" can't be synchronized..not
> that I know of without changing the TC5.0 and 5.5 code.  Also the JSTL
> libraries, and many other jakarta libraries.


Also if you access the PageContext in a jsp and use the scoped methods the ones
accessing APPLICATION and REQUEST scope are already synchronized, yet the
session is not.  Also, now you have to synchronize not only session calls, but
you also have to synchronize the calls to the PageContext in a JSP.  So, instead
of some type of a performance gain you end up with double the monitors for those
objects and then the one for the session.  

I think these are the points people are making.....there is so much to change
now that a patch now and maybe a refactoring could be done and an announcement
that the functionality is changing.  But, before TC decides to do that maybe
they should see how all of the other servers are handling this.  Because if they
are handing this with synchronization and others are writing code not worrying
about synchronizing........they are not going to rewrite to use Tomcat later and
what about code targeted for a container like Oracle or Sun ONE that someone is
using in TC which is not synchronized...point being if the user base gets run
off whats the point, and who will be left donating to the project.  I really
think this is too subtle of a thing to say it's by the spec....at least for the
time being, and maybe it should always and forever remain synchronized depending
on what is going on with the real world usage of the spec in other cases.  There
are other situations where you don't even have access to synchronize the
call...again tags, and I'm sure some other API calls directly manipulating the
session.  I have found no where in other Tomcat code synchronizing the session
access, so there are other issues or fix this one.

I haven't even seen comments on all of the other issues in the TC code accessing
the session or the other jakarta projects from anyone but those arguing this
needs to be fixed.  So, what's the story?  Is this one thing changing or are all
of the others changing or is nothing changing (being fixed)?

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