session serialization

[evan <sp...@eustace.net>]

No one answered last time, trying again :(

  I am trying to better understand if it is possible to minimize session 
replication in a clustered environment.

The Tapestry online docs say this:

"Because the internal state of the engine can change, the framework will 
re-store the engine into the HttpSession at the end of most requests. 
This ensures that any changes to the Visit object are properly replicated."

(http://jakarta.apache.org/tapestry/doc/TapestryUsersGuide/state.engine.html)

In Tapestry in Action, on page 276 there is a footnote about this same 
topic that says:

"Actually, setAttribute() doesn't occur on every request; some simple 
optimizations are employed to avoid invoking setAttribute() when 
internal state can't have changed, such as a request that does not 
change a persistent page property and does not even access the Visit 
object."

  From what I can tell through looking through the source, it looks like 
calling getVisit() will result in a setAttribute() call. Is this correct?

I just want to know if I am wasting my time trying to find ways of 
minimizing session serialization in Tapestry. All clients using this 
high volume webapp will have a session.
  On the one hand, I'd like to avoid the situation where pretty much all 
requests trigger a session serialization to the backup server for that 
session. On the other, if I decide to use Tapestry, I don't want to 
break its use model in the process.

Does anyone have experience of using Tapestry in a similar situation, 
clustered, high-volume, all users have a session? Any tips on performance?

thanks,
evan





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

Re: session serialization

[evan <sp...@eustace.net>]

Thanks for the Tip Kent...

Kent Tong wrote:
> evan <spam <at> eustace.net> writes:
> 
> 
>>No one answered last time, trying again :(
> 
> 
> I did, but somehow you didn't see it.
> 

Sorry, perhaps my thunderbird newsreader dropped that mail header for 
some reason.

> 
>>  From what I can tell through looking through the source, it looks like 
>>calling getVisit() will result in a setAttribute() call. Is this correct?
> 
> 
> Yes.
> 
> 
>>Does anyone have experience of using Tapestry in a similar situation, 
>>clustered, high-volume, all users have a session? Any tips on performance?
> 
> 
> You may try the following hack:
> 
> 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();
>     }
>   }
> }
> 
> Then register to use MyEngine. Of course, you're
> advised to submit a feature request in the bug DB
> of Tapestry.
> 
> 

That makes sense for the visit object access. It turns out I was looking 
at the wrong codebase (I had checked out the latest version from CVS. - 
3.1 Alpha) Unfortunately it looks like this particular solution won't 
work in 3.1, as it seems the engine classes are being refactored.
  With regard to posting a feature request, I will do that. I am still a 
new user (halfway through the TIA book) So perhaps I will finish it and 
learn more about the system before adding a feature request.

Thanks,
Evan





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

Re: session serialization

[Kent Tong <ke...@cpttm.org.mo>]

evan <spam <at> eustace.net> writes:

> 
> No one answered last time, trying again :(

I did, but somehow you didn't see it.

>   From what I can tell through looking through the source, it looks like 
> calling getVisit() will result in a setAttribute() call. Is this correct?

Yes.

> Does anyone have experience of using Tapestry in a similar situation, 
> clustered, high-volume, all users have a session? Any tips on performance?

You may try the following hack:

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();
    }
  }
}

Then register to use MyEngine. Of course, you're
advised to submit a feature request in the bug DB
of Tapestry.



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