[jira] Resolved: (TAPESTRY-267) more control of session serialization triggers for clustered environment

["Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org>]

     [ http://issues.apache.org/jira/browse/TAPESTRY-267?page=all ]

Jesse Kuhnert resolved TAPESTRY-267.
------------------------------------

    Resolution: Incomplete
      Assignee: Jesse Kuhnert

For now, since it's been open for so long. If documentation needs updating or something I can probably apply a patch somewhere?

> more control of session serialization triggers for clustered environment
> ------------------------------------------------------------------------
>
>                 Key: TAPESTRY-267
>                 URL: http://issues.apache.org/jira/browse/TAPESTRY-267
>             Project: Tapestry
>          Issue Type: New Feature
>          Components: Documentation, Framework
>         Environment:  
>            Reporter: Evan E
>         Assigned To: Jesse Kuhnert
>
> Environment:
>  High volume application, with clustered application servers (WL 8.1), using in-memory replication with a primary (sticky) server, and a secondary back up server. 99% plus of requests coming from users with http sessions.
> Problem:
>  The default behaviour of Tapestry seems to be that setAttribute() will be called on the httpsession at the end of each request cycle if getVisit() is called. Causing session-replication to occur.
>  In the evironment described above, the secondary server plays the role of a backup for a given session in the event of server failure. Server failure is a rare event (thankfully), so the performance loss incurred by every request triggering a session serialization is not ideal.
>  As such it would be good to have the option of accessing the Visit object in such a way that setAttribute() would not be called (Leaving aside persistent properties, which we would use only where necessary.)
> Solutions:
> If there is a way of retrieving the Visit object without triggering setAttribute() then the application (for the case I am considering at any rate) can use a user identifier to retrieve and manage data from the business objects relevant to the user. We will have fine grained control over cached business objects in the cluster cache.
> Don't use the Visit object at all - access user identifier directly with HttpSession?
> In addition to above, in application design use persistent properties only where necessary.
> I am not sure if there is anything that should/could be changed in the framework to support this, or whether the solution is just documenting some strategies. 
> The following was suggested by Kent Tong on the user list as an option for the 3.0.1 codebase:
> class MyEngine extends BaseEngine {
>   boolean gettingVisitForReading = false;
>   public Object getVisitForReading() {
>     gettingVisitForReading = true;
>     try {
>       return super.getVisit();
>     } finally {
>       gettingVisitForReading = false;
>     }
>   }
>   protected void markDirty() {
>     if (!gettingVisitForReading) {
>        super.markDirty();
>     }
>   }
> }
> But this seems to be incompatible with 3.1 Alpha.
> I did look through the newer codebase, but don't feel qualified at this point to propose a generic solution in terms of extending base classes.
> The assumptions I am making above is that persistent properties, and getVisit() calls are the two main factors that will trigger session serialization. If there are more then perhaps some documentation in general around what these are, and strategies to manage them in app design could be a solution.
> I am new to Tapestry and am only at chapter 8 in TIA, so I apologise if there is something I missed.

-- 
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