I must say that even if tapestry isn't using synchronized having to acquire a Lock to get access to the HttpSession objects scares me well.
I feel the first statement in the issue description seems somehow naive, what is described there is the nature of web app from day one, obviously AJAX has made things worse but, having multiple threads accessing the HttpSession is not a new thing. Howard what is your motivation behind this implementation? Cheers On Sun, Jan 13, 2013 at 12:57 PM, Denis Stepanov <[email protected]>wrote: > Changes introduced in https://issues.apache.org/jira/browse/TAP5-2049bring > some bad consequences. > > Now, if your request accesses the session every other request will wait to > access the session until the previous request is done, it means long > running request could block all other requests, this bring major > performance issues. > > Some points I have mentioned in the comments: > > - We have many concurrent ajax request, this change means major > performance issue for us! > - This will not work in a clustered environment, the clustered session > class shouldn't inherit the locks functionality. > - Tapestry should not do this by default, any kind of synchronization > between the requests is bad idea and should be avoided at any cost. > > Cases when you need to synchronize session's state should be dealt with > individually, not forcing everyone into using it. > > Tapestry should not try to outsmart the servlet specification, the session > object should only be wrapping the HttpSession without bringing some major > behavior changes. Session synchronization is anti-pattern and should not be > promoted in a first place. > > Denis -- Massimo http://meridio.blogspot.com
