[ http://issues.apache.org/jira/browse/TAPESTRY-1075?page=comments#action_12430401 ] Henri Dupre commented on TAPESTRY-1075: ---------------------------------------
Thanks Jesse! With a little googling, I found out that we are not the only ones to experience this issue: http://www.agilocity.com/roller/page/wrast The bottom line is thread synchronization and is not specific at all to hibernate and not even to tapestry. user launches an url -> thread n does something on the session but if the user clicks before the rendering is finished (or in our case we have a popup that comes at the same time than the page), there will be another thread m that uses the same instance of the session objects and might do operations on the objects. If your session object has a list and both add and delete something then blam, you'll get a nasty synchronization error. This is the basic problem... To make things worse, if you have hibernate objects in the ASOs, you'll have in one thread some operations on the hibernate objects associated with one hibernate session and on the other thread there will be operations on the same objects with a different hibernate session. The "usual" solution (I've seen it also on tomcat mailing list and in hibernate forums) is to prevent executing more than one request per user. But it is not necessarily the best for the end user. If you can provide different copies of the ASOs on each request, you'll skip all these issues. Does this make more sense? > 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]
