You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Henri Dupre (JIRA)" <ta...@jakarta.apache.org> on 2006/08/24 08:48:53 UTC
[jira] Created: (TAPESTRY-1075) Provide deep copies of the session
objets to prevent synchronization issues with concurrent requests
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.1, 4.0, 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAPESTRY-1075) Provide deep copies of the
session objets to prevent synchronization issues with concurrent requests
Posted by "Henri Dupre (JIRA)" <ta...@jakarta.apache.org>.
[ 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAPESTRY-1075) Provide deep copies of the
session objets to prevent synchronization issues with concurrent requests
Posted by "Nick Westgate (JIRA)" <ta...@jakarta.apache.org>.
[ 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAPESTRY-1075) Provide deep copies of the
session objets to prevent synchronization issues with concurrent requests
Posted by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-1075?page=comments#action_12430390 ]
Jesse Kuhnert commented on TAPESTRY-1075:
-----------------------------------------
Only commenting so you don't think you are being ignored.
My first gut reaction when hearing about this was "why" ? I have been using objects in servlet session objects for what feels like is close to a decade now with no problems at all.
Are the issues within session scope manager having to do with attached hibernate objects and lazy loading / locking of objects?
I'm not saying the problem shouldn't be solved somewhere, I'm just wondering if Tapestry really needs adjusting in this instance.
...Unless there is a different naught synchronization thing gonig on I don't know about?
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Resolved: (TAPESTRY-1075) Provide deep copies of the session
objets to prevent synchronization issues with concurrent requests
Posted by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-1075?page=all ]
Jesse Kuhnert resolved TAPESTRY-1075.
-------------------------------------
Resolution: Won't Fix
Assignee: Jesse Kuhnert
Object copying is something I'd like to avoid like the plague. If tapestry lets you override how it's done I think that's enough.
> 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
> Assigned To: Jesse Kuhnert
>
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org