[jira] Commented: (TAP5-834) BaseOptimizedSessionPersistedObject does not work correctly with Tomcat & Jetty

["Josh Canfield (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TAP5-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935606#action_12935606 ] 

Josh Canfield commented on TAP5-834:
------------------------------------

I believe this fix caused TAP5-1355 -  Threading issue with SessionStateObjects

For the fraction of a second that the SSO's session attribute is set to null other requests from the same request are looking up the SSO from the same session and re-creating the SSO because it's null.

The original problem from the user list (http://tapestry.1045711.n5.nabble.com/Threading-and-SSOs-again-td3276880.html) was regarding securing images. For this use case it's possible that a single page refresh could cause many concurrent requests for the same SSO. Especially if you use domain naming tricks to get around the HTTP request per server limit.

I used the sample from TAP5-1355 to reproduce the problem, removed the setting of null and could no longer reproduce the problem.

> BaseOptimizedSessionPersistedObject does not work correctly with Tomcat & Jetty
> -------------------------------------------------------------------------------
>
>                 Key: TAP5-834
>                 URL: https://issues.apache.org/jira/browse/TAP5-834
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.1.0.0, 5.1.0.1, 5.1.0.2, 5.1.0.3, 5.1.0.4, 5.1.0.5, 5.0.18
>            Reporter: Andy Blower
>            Assignee: Howard M. Lewis Ship
>            Priority: Critical
>             Fix For: 5.2.0
>
>         Attachments: TAP5-834-patch.txt
>
>
> OptimizedSessionPersistedObject's suggestion for implementing isSessionPersistedObjectDirty(), as used by BaseOptimizedSessionPersistedObject, does not work correctly with Tomcat & Jetty. (and quite possibly other servlet containers too, but we only use Jetty & Tomcat so have only confirmed it with them)
> OptimizedSessionPersistedObject model relies on the servlet container session object triggering a HttpSessionBindingEvent when an object is re-stored in the session to reset the dirty flag. I've only looked at the source of Tomcat 5.5 and 6 but when an object is replaced in the session using setAttribute() the new object and the existing object are compared by reference only, if they both refer to the same object then no HttpSessionBindingEvent is triggered.
> From Tomcat StandardSession.java:
>         // Call the valueBound() method if necessary
>         if (notify && value instanceof HttpSessionBindingListener) {
>             // Don't call any notification if replacing with the same value
>             Object oldValue = attributes.get(name);
>             if (value != oldValue) {
>                 event = new HttpSessionBindingEvent(getSession(), name, value);
>                 try {
>                     ((HttpSessionBindingListener) value).valueBound(event);
>                 } catch (Throwable t){
>                     manager.getContainer().getLogger().error
>                     (sm.getString("standardSession.bindingEvent"), t); 
>                 }
>             }
>         }
> So, using OptimizedSessionPersistedObject, there is currently no way of setting the dirty flag to false after the object has been saved in the session - hence we are propagating all of the SSOs across the cluster all of the time because the dirty flag stays set to true.
> I think there are two possible solutions to this issue - I prefer the first by a large margin, but both modify the SessionImpl.restoreDirtyObjects() method.
> 1) Add a new method to OptimizedSessionPersistedObject interface to reset the dirty flag, and a corresponding method in SessionPersistedObjectAnalyzer - implementing them as appropriate, then call the new reset method after setting the session attribute in SessionImpl.restoreDirtyObjects().
> 2) Remove the session attribute before adding it in SessionImpl.restoreDirtyObjects(). Although I have a worry that this may potentially cause hard to find concurrency problems.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.