You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Arno Haase <ar...@haase-consulting.com> on 2012/05/07 15:08:40 UTC
Best Practices for @Persist
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I know the mechanics of @Persist and Session State. But I am looking
for advice on how to deal with some common challenges using Tapestry:
* Let's say a page stores stuff in the HttpSession using @Persist -
directly or e.g. through use of the Grid component. Whenever a user
opens that page twice in different browser tabs, those two instances
share server side state, and sorting one of the grids by name can
affect the other.
* There can be (rare but tricky) race conditions if two AJAX calls are
fired concurrently and operate on session data - all of a sudden there
is multithreaded logic in the server.
These are fairly common but pretty tricky issues. I know @Persist has
a configurable strategy for storing state that can be used to store
stuff in the browser, avoiding session use completely.
But does Tapestry provide support for dealing with these issues when
actually storing stuff in the HttpSession?
Thanks
- - Arno
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+nyVgACgkQbmZsMyUPuXRiFgCfUPbEyZyxpz1+JTDz/hGzMSWC
Dw8Ani8Dr/3uIQJp+nOJ12OYuWWFhxks
=yDKR
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Best Practices for @Persist
Posted by Arno Haase <ar...@haase-consulting.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Yes, I try to be as stateless as (reasonably) possible. It's just that
core components - e.g. Grid - use @Persist, and so I explore ways to
use them robustly. Thanks again!
Am 07.05.2012 17:09, schrieb Thiago H. de Paula Figueiredo:
> On Mon, 07 May 2012 11:34:02 -0300, Arno Haase
> <ar...@haase-consulting.com> wrote:
>
>> Thanks for pointing out Tynamo! I'll look into it, looks like it
>> is what I was looking for.
>
> I forgot to mention something:
>
> * Try to avoid using @Persist. In many scenarios the page
> activation context is able to replace @Persist. * If not possible
> to avoid @Persist, use flash persistence if possible.
>
> @SessionState is harder to avoid, but is mostly used for data
> which isn't changed during the user session.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+oEmMACgkQbmZsMyUPuXRr9wCfYom654dHqYheXAYZ0DwrUtXY
jN4AoPqXx8VBf5uh9qOgScECHJdXH+Xm
=v7gf
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Best Practices for @Persist
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Mon, 07 May 2012 11:34:02 -0300, Arno Haase
<ar...@haase-consulting.com> wrote:
> Thanks for pointing out Tynamo! I'll look into it, looks like it is
> what I was looking for.
I forgot to mention something:
* Try to avoid using @Persist. In many scenarios the page activation
context is able to replace @Persist.
* If not possible to avoid @Persist, use flash persistence if possible.
@SessionState is harder to avoid, but is mostly used for data which isn't
changed during the user session.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Best Practices for @Persist
Posted by Arno Haase <ar...@haase-consulting.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thanks for pointing out Tynamo! I'll look into it, looks like it is
what I was looking for.
Am 07.05.2012 15:14, schrieb Thiago H. de Paula Figueiredo:
> On Mon, 07 May 2012 10:08:40 -0300, Arno Haase
> <ar...@haase-consulting.com> wrote:
>
>> I know the mechanics of @Persist and Session State. But I am
>> looking for advice on how to deal with some common challenges
>> using Tapestry:
>>
>> * Let's say a page stores stuff in the HttpSession using @Persist
>> - directly or e.g. through use of the Grid component. Whenever a
>> user opens that page twice in different browser tabs, those two
>> instances share server side state, and sorting one of the grids
>> by name can affect the other.
>
> Tapestry itself doesn't provide a solution for this kind of
> problem, but tapestry-conversations from the Tynamo project does:
> http://docs.codehaus.org/display/TYNAMO/tapestry-conversations+guide.
>
>
>> * There can be (rare but tricky) race conditions if two AJAX
>> calls are fired concurrently and operate on session data - all of
>> a sudden there is multithreaded logic in the server.
>
> If you do have something that could have a problem with multiple
> calls for the same data, there's no good-for-all-scenarios solution
> possible. You can use a service to do this shared data access and
> does the appropriate threading logic.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+n3VoACgkQbmZsMyUPuXRcCwCgwe3Nom0IoB0NbYGXeGe8RZ9L
u1cAoMuHwNPD9whnFsLlbRW6Ii9aLTPB
=IK/A
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Best Practices for @Persist
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Mon, 07 May 2012 10:08:40 -0300, Arno Haase
<ar...@haase-consulting.com> wrote:
> I know the mechanics of @Persist and Session State. But I am looking
> for advice on how to deal with some common challenges using Tapestry:
>
> * Let's say a page stores stuff in the HttpSession using @Persist -
> directly or e.g. through use of the Grid component. Whenever a user
> opens that page twice in different browser tabs, those two instances
> share server side state, and sorting one of the grids by name can
> affect the other.
Tapestry itself doesn't provide a solution for this kind of problem, but
tapestry-conversations from the Tynamo project does:
http://docs.codehaus.org/display/TYNAMO/tapestry-conversations+guide.
> * There can be (rare but tricky) race conditions if two AJAX calls are
> fired concurrently and operate on session data - all of a sudden there
> is multithreaded logic in the server.
If you do have something that could have a problem with multiple calls for
the same data, there's no good-for-all-scenarios solution possible. You
can use a service to do this shared data access and does the appropriate
threading logic.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org