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