You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Ben Titmarsh <be...@hotmail.co.uk> on 2014/04/15 12:14:41 UTC
Over Reliance on Session Storage
Hi Everyone,
My application is under a level of load where I am starting to regret a somewhat naive over reliance on the @Persist annotation. My pages probably contain far too much state and as a result my memory utilisation is going through the ceiling and I'm having to perform semi-regular restarts.
In addition the lack of conversational state means that I have issues with multiple tabs being open - same old story I guess.
So what I'd like to know is how should I be tackling this in Tapestry 5.3? I had a look around and found the third party Tynamo library that has a conversational state implementation but it doesn't look like it's seen an update for 3 years. Is this still the best way forward?
I'm probably going to need to tackle this in baby steps and will likely start out by littering my code with componentResources.discardPersistentFieldChanges() but I'd like to know what other approaches have worked for you guys.
Thanks a lot,
Ben.
Re: Over Reliance on Session Storage
Posted by Lance Java <la...@googlemail.com>.
I only use the HttpSession as a last resort. I will always favour the
stateless approach using:
1. Page activation context (onActivate() / onPassivate() or
@PageActivationContext)
2. Event context (actionlink / eventlink)
3. Posting hidden inputs
One caveat to this is that the logged in user is always HttpSession scoped
for security (never trust a url). In my opinion, users who are not logged
in shouldn't require a session.
This has many benefits:
1. Improves scalability by reducing server load
2. Makes your links bookmarkable
3. Allows multiple browser tabs to the same page(s) without conflict
4. Makes clustering easier
Some further reading
https://tapestry.apache.org/performance-and-clustering.html
Re: Over Reliance on Session Storage
Posted by Luke Wilson-Mawer <lu...@gmail.com>.
On Tue, Apr 15, 2014 at 2:31 PM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Tue, 15 Apr 2014 07:48:47 -0300, Luke Wilson-Mawer <
> lukewilsonmawer@gmail.com> wrote:
>
> A slightly more significant departure might be to start replacing your
>> pages and components with stateless rest endpoints using Tynamo's
>> tapestry-resteasy, a piece at a time. We've done this with a couple of
>> our components, moving them into angularjs.
>>
>
> This is a webapp rewrite almost from scratch (at least the web UI part)
> and doesn't really solve the problem of over-reliance on session storage.
Yeah that's completely true, it is basically a rewrite apart from the
service layer but it would solve scaling issues around keeping state in the
session by moving the state to the client.
However, I'm sure there are plenty of ways you can solve the issue without
doing this.
>
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Over Reliance on Session Storage
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Tue, 15 Apr 2014 07:48:47 -0300, Luke Wilson-Mawer
<lu...@gmail.com> wrote:
> A slightly more significant departure might be to start replacing your
> pages and components with stateless rest endpoints using Tynamo's
> tapestry-resteasy, a piece at a time. We've done this with a couple of
> our components, moving them into angularjs.
This is a webapp rewrite almost from scratch (at least the web UI part)
and doesn't really solve the problem of over-reliance on session storage.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Over Reliance on Session Storage
Posted by Luke Wilson-Mawer <lu...@gmail.com>.
Hi Ben,
Have you tried using Tapestry's client persistence? I'm not up to speed
with how well it works now.
A slightly more significant departure might be to start replacing your
pages and components with stateless rest endpoints using Tynamo's
tapestry-resteasy, a piece at a time. We've done this with a couple of our
components, moving them into angularjs.
I'd also suggest that trying to stop users opening multiple tabs for
internal links (e.g. target="_blank") might alleviate the multiple tab
problem a little in the short term.
Cheers,
Luke
On Tue, Apr 15, 2014 at 11:14 AM, Ben Titmarsh
<be...@hotmail.co.uk>wrote:
> Hi Everyone,
>
> My application is under a level of load where I am starting to regret a
> somewhat naive over reliance on the @Persist annotation. My pages probably
> contain far too much state and as a result my memory utilisation is going
> through the ceiling and I'm having to perform semi-regular restarts.
>
> In addition the lack of conversational state means that I have issues with
> multiple tabs being open - same old story I guess.
>
> So what I'd like to know is how should I be tackling this in Tapestry 5.3?
> I had a look around and found the third party Tynamo library that has a
> conversational state implementation but it doesn't look like it's seen an
> update for 3 years. Is this still the best way forward?
>
> I'm probably going to need to tackle this in baby steps and will likely
> start out by littering my code with
> componentResources.discardPersistentFieldChanges() but I'd like to know
> what other approaches have worked for you guys.
>
> Thanks a lot,
> Ben.
>
Re: Over Reliance on Session Storage
Posted by Barry Books <tr...@gmail.com>.
Just switching to @PageActivationContext and @ActivationRequestParmeter
will solve most of your problems.It's also best if your components are
stateless.
On Tue, Apr 15, 2014 at 5:14 AM, Ben Titmarsh <be...@hotmail.co.uk>wrote:
> Hi Everyone,
>
> My application is under a level of load where I am starting to regret a
> somewhat naive over reliance on the @Persist annotation. My pages probably
> contain far too much state and as a result my memory utilisation is going
> through the ceiling and I'm having to perform semi-regular restarts.
>
> In addition the lack of conversational state means that I have issues with
> multiple tabs being open - same old story I guess.
>
> So what I'd like to know is how should I be tackling this in Tapestry 5.3?
> I had a look around and found the third party Tynamo library that has a
> conversational state implementation but it doesn't look like it's seen an
> update for 3 years. Is this still the best way forward?
>
> I'm probably going to need to tackle this in baby steps and will likely
> start out by littering my code with
> componentResources.discardPersistentFieldChanges() but I'd like to know
> what other approaches have worked for you guys.
>
> Thanks a lot,
> Ben.
>
Re: Over Reliance on Session Storage
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Tue, 15 Apr 2014 07:14:41 -0300, Ben Titmarsh
<be...@hotmail.co.uk> wrote:
> Hi Everyone,
Hi!
> So what I'd like to know is how should I be tackling this in Tapestry
> 5.3? I had a look around and found the third party Tynamo library that
> has a conversational state implementation but it doesn't look like it's
> seen an update for 3 years. Is this still the best way forward?
If you really need conversational state, yes. For places which don't need
that, you can replace most session state by using the page activation
context and/or @PageActivationContext.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org