[ 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to