Howard, is there a particular use case for this? This sounds like an overkill and unnecessary. There are also most likely locking going on just to get to the per thread access to the field even before the session gets accessed. I view is change as a performance killer as well with no benefits whatsoever.
Good catch Denis. On Jan 13, 2013, at 5:57 AM, Denis Stepanov <[email protected]> wrote: > Changes introduced in https://issues.apache.org/jira/browse/TAP5-2049 bring > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
