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
