[ http://issues.apache.org/jira/browse/TAPESTRY-1075?page=comments#action_12430407 ] Nick Westgate commented on TAPESTRY-1075: -----------------------------------------
Hi Henri. I'm using Tapestry 3, and have been using the "OnJava" solution (a filter) for a couple of years. It works well enough, but I've always considered this a 'gotcha' that the framework (or even servlet API) should handle. Your solution of using multiple ASO copies sounds dangerous. Won't changes in one ASO overwrite changes in the other? Perhaps not in your use case, but in general some coordination would be required to prevent this. Cheers, Nick. > Provide deep copies of the session objets to prevent synchronization issues > with concurrent requests > ---------------------------------------------------------------------------------------------------- > > Key: TAPESTRY-1075 > URL: http://issues.apache.org/jira/browse/TAPESTRY-1075 > Project: Tapestry > Issue Type: Improvement > Components: Core > Affects Versions: 4.0, 4.1, 4.0.1, 4.0.2 > Reporter: Henri Dupre > > this aims to improve Tapestry behavior with concurrent requests from the same > user. They may lead to synchronization issue because all concurrent requests > will share the same instance of the session objects. > An elegant and efficient solution can be implemented by improving the > SessionScopeManager and by providing deep copies of the session objects when > a session object is requested. The session objects then get cached by the > ApplicationStateManager and get stored at the end of the request by the > SessionScopeManager. > This way concurrent requests will execute correctly and the request that ends > up last overrides the other requests. And this will be totally transparent > for any application. > An efficient deep copy mecanism can be found at > http://javatechniques.com/public/java/docs/basics/faster-deep-copy.html. > On my tests, a deep copy of our visit object is hardly measurable, < 1 ms and > the overhead of deep copies is probably lower than any synchronization > mecanism. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
