tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Lewis Ship <hls...@gmail.com>
Subject Re: [jira] Commented: (TAPESTRY-267) more control of session serialization triggers for clustered environment
Date Wed, 16 Feb 2005 18:01:12 GMT
Yep, that's pretty much what I had envisioned.  You then have to map a
stategy name to a ASM service, and use that name w.r.t. your ASO.

Gotta catch a flight, bye!


On Wed, 16 Feb 2005 18:30:06 +0100 (CET), Evan E (JIRA)
<tapestry-dev@jakarta.apache.org> wrote:
>      [ http://issues.apache.org/jira/browse/TAPESTRY-267?page=comments#action_59264 ]
> 
> Evan E commented on TAPESTRY-267:
> ---------------------------------
> 
> I'd be happy to attempt a simple tutorial for doing this if that is worthwhile.
> 
> Where would the configuration point be in 3.1 for specifying a custom ApplicationStateManager
implementation?
> I see that ApplicationStateManagerImpl is defined in tapestry.state.xml, but presume
that is not where a user would provide an implementation class.
> 
> Would something along the lines of the below work?
> 
> public interface IPersistenceControlled {
>     /**
>      * @return a boolean indicating whether the object needs to be persisted.
>      */
>     public abstract boolean isDirty();
> 
>     /**
>      * @param dirty - sets the persistence 'dirty' flag for the object.
>      */
>     public abstract void setDirty(boolean dirty);
> }
> 
> public class StateControlStateManager extends ApplicationStateManagerImpl {
> 
>     public void store(String objectName, Object stateObject) {
>         if (stateObject instanceof IPersistenceControlled) {
>             if ( ((IPersistenceControlled)stateObject).isDirty() ) {
>                 super.store(objectName, stateObject);
>             }
>         }
>     }
> }
> 
> > more control of session serialization triggers for clustered environment
> > ------------------------------------------------------------------------
> >
> >          Key: TAPESTRY-267
> >          URL: http://issues.apache.org/jira/browse/TAPESTRY-267
> >      Project: Tapestry
> >         Type: New Feature
> >   Components: Framework, Documentation
> >  Environment:
> >     Reporter: Evan E
> 
> >
> > 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
> -
> If you want more information on JIRA, or have a bug to report see:
>    http://www.atlassian.com/software/jira
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> 
> 


-- 
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


Mime
View raw message