You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Jim O'Callaghan <jc...@yahoo.co.uk> on 2010/01/06 14:16:23 UTC

Persisting state without HTTP Session

Hi,

Can anyone advise on the preferred way of persisting state between pages
without using HTTP Session?  PageActivationContext using Object[] looks
promising but I don't want long urls (from serialized objects) and there is
more data to share than a defined number of keys - I'm looking for something
that uses POST params ...?  Thanks.

Regards,
Jim.

RE: Persisting state without HTTP Session

Posted by Jim O'Callaghan <jc...@yahoo.co.uk>.
Ulrich, Lutz,

Thanks for the very informative replies.  Hopefully they will be useful to others also.

Regards,
Jim.

-----Original Message-----
From: Lutz Hühnken [mailto:lh.tapestry.list@googlemail.com]
Sent: 06 January 2010 15:56
To: Tapestry users
Subject: Re: Persisting state without HTTP Session


Jim,

You still have some different options to pursue in a cluster..

- "sticky" sessions, so that requests of the same user will go to the
same server in the cluster. Good for load balancing, but if a server
fails, the users of that server will loose their session.

- session replication in the cluster - this seems to be the approach
you are thinking of. Here I would indeed imagine that the amount of
data you store in the session heavily influences performance.

- persist the session. Could be in clustered rdbms, could be one of
these distributed key-value stores that are all the rage these days,
like Cassandra or HBase.

Maybe you could let us know what you ended up doing, once you've
finished your project.

Good luck,

Lutz


On Wed, Jan 6, 2010 at 4:37 PM, Jim O'Callaghan <jc...@yahoo.co.uk> wrote:
> Lutz,
>
> You raise some very interesting points.  I've replied to some of the other posters regarding the reasons I was trying to minimise session use, though taking their replies on board and your own email I think the best course of action is to proceed with using the session state and just minimising the amount of data held.  Thanks for your contributions.
>
> Regards,
> Jim.



-- 
altocon GmbH
http://www.altocon.de/
Software Development, Consulting
Hamburg, Germany

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


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


Re: Persisting state without HTTP Session

Posted by Lutz Hühnken <lh...@googlemail.com>.
Jim,

You still have some different options to pursue in a cluster..

- "sticky" sessions, so that requests of the same user will go to the
same server in the cluster. Good for load balancing, but if a server
fails, the users of that server will loose their session.

- session replication in the cluster - this seems to be the approach
you are thinking of. Here I would indeed imagine that the amount of
data you store in the session heavily influences performance.

- persist the session. Could be in clustered rdbms, could be one of
these distributed key-value stores that are all the rage these days,
like Cassandra or HBase.

Maybe you could let us know what you ended up doing, once you've
finished your project.

Good luck,

Lutz


On Wed, Jan 6, 2010 at 4:37 PM, Jim O'Callaghan <jc...@yahoo.co.uk> wrote:
> Lutz,
>
> You raise some very interesting points.  I've replied to some of the other posters regarding the reasons I was trying to minimise session use, though taking their replies on board and your own email I think the best course of action is to proceed with using the session state and just minimising the amount of data held.  Thanks for your contributions.
>
> Regards,
> Jim.



-- 
altocon GmbH
http://www.altocon.de/
Software Development, Consulting
Hamburg, Germany

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


RE: Persisting state without HTTP Session

Posted by Jim O'Callaghan <jc...@yahoo.co.uk>.
Lutz,

You raise some very interesting points.  I've replied to some of the other posters regarding the reasons I was trying to minimise session use, though taking their replies on board and your own email I think the best course of action is to proceed with using the session state and just minimising the amount of data held.  Thanks for your contributions.

Regards,
Jim.

-----Original Message-----
From: Lutz Hühnken [mailto:lh.tapestry.list@googlemail.com]
Sent: 06 January 2010 15:26
To: Tapestry users
Subject: Re: Persisting state without HTTP Session


I see. There wouldn't be much handling, though, one could probably
implement a "cookie" persistence strategy, so that you could use the
@Persist annotation. Doesn't that even exist already?

The thing you are in favor of, using post.. there'll be some
disadvantages. I assume you won't be using redirect-after-post much,
if you don't want to keep state on the server side. You would have to
disable that, as it is the default in Tapestry.

I could imagine having a central dispatcher... every post goes to that
central dispatcher, the page to be rendered would be one of the
parameters. The other parameters would constitute the context for that
page. That would be kept track of with hidden form fields. Might be
possible, but not a nice solution. No bookmarks, possibly no
navigation with browser back - forward buttons..

You could write your context into a database after request processing,
and read it on the next request. Of course that would be exactly the
same as using a session (in fact, you can configure most servers to
store the session in a database). Only slower (than in-memory
sessions).

Well, now we know why people came up with the session concept. It is
actually quite a good approach. What was the reason again you don't
want to use it?


On Wed, Jan 6, 2010 at 3:04 PM, Jim O'Callaghan <jc...@yahoo.co.uk> wrote:
> Lutz,
>
> Thanks for the response - Cookies would be a last resort - I don't want to be managing cookies and also feel it makes the app more breakable (fundamental state could be broken with browser security settings).  What I'm after is something akin to PageActivationContext but that passes the relevant object(s) using Request parameters rather than the querystring / url - thanks.
>
> Regards,
> Jim.
>
> -----Original Message-----
> From: Lutz Hühnken [mailto:lh.tapestry.list@googlemail.com]
> Sent: 06 January 2010 13:50
> To: Tapestry users
> Subject: Re: Persisting state without HTTP Session
>
>
> Cookies come to mind, would that be an option?
>
>
> On Wed, Jan 6, 2010 at 2:16 PM, Jim O'Callaghan <jc...@yahoo.co.uk> wrote:
>> Hi,
>>
>> Can anyone advise on the preferred way of persisting state between pages
>> without using HTTP Session?  PageActivationContext using Object[] looks
>> promising but I don't want long urls (from serialized objects) and there is
>> more data to share than a defined number of keys - I'm looking for something
>> that uses POST params ...?  Thanks.
>>
>> Regards,
>> Jim.
>>



-- 
altocon GmbH
http://www.altocon.de/
Software Development, Consulting
Hamburg, Germany

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


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


Re: Persisting state without HTTP Session

Posted by Lutz Hühnken <lh...@googlemail.com>.
I see. There wouldn't be much handling, though, one could probably
implement a "cookie" persistence strategy, so that you could use the
@Persist annotation. Doesn't that even exist already?

The thing you are in favor of, using post.. there'll be some
disadvantages. I assume you won't be using redirect-after-post much,
if you don't want to keep state on the server side. You would have to
disable that, as it is the default in Tapestry.

I could imagine having a central dispatcher... every post goes to that
central dispatcher, the page to be rendered would be one of the
parameters. The other parameters would constitute the context for that
page. That would be kept track of with hidden form fields. Might be
possible, but not a nice solution. No bookmarks, possibly no
navigation with browser back - forward buttons..

You could write your context into a database after request processing,
and read it on the next request. Of course that would be exactly the
same as using a session (in fact, you can configure most servers to
store the session in a database). Only slower (than in-memory
sessions).

Well, now we know why people came up with the session concept. It is
actually quite a good approach. What was the reason again you don't
want to use it?


On Wed, Jan 6, 2010 at 3:04 PM, Jim O'Callaghan <jc...@yahoo.co.uk> wrote:
> Lutz,
>
> Thanks for the response - Cookies would be a last resort - I don't want to be managing cookies and also feel it makes the app more breakable (fundamental state could be broken with browser security settings).  What I'm after is something akin to PageActivationContext but that passes the relevant object(s) using Request parameters rather than the querystring / url - thanks.
>
> Regards,
> Jim.
>
> -----Original Message-----
> From: Lutz Hühnken [mailto:lh.tapestry.list@googlemail.com]
> Sent: 06 January 2010 13:50
> To: Tapestry users
> Subject: Re: Persisting state without HTTP Session
>
>
> Cookies come to mind, would that be an option?
>
>
> On Wed, Jan 6, 2010 at 2:16 PM, Jim O'Callaghan <jc...@yahoo.co.uk> wrote:
>> Hi,
>>
>> Can anyone advise on the preferred way of persisting state between pages
>> without using HTTP Session?  PageActivationContext using Object[] looks
>> promising but I don't want long urls (from serialized objects) and there is
>> more data to share than a defined number of keys - I'm looking for something
>> that uses POST params ...?  Thanks.
>>
>> Regards,
>> Jim.
>>



-- 
altocon GmbH
http://www.altocon.de/
Software Development, Consulting
Hamburg, Germany

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


Re: Persisting state without HTTP Session

Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 06 Jan 2010 12:04:44 -0200, Jim O'Callaghan  
<jc...@yahoo.co.uk> escreveu:

> What I'm after is something akin to PageActivationContext but that  
> passes the relevant object(s) using Request parameters rather than the  
> querystring / url - thanks.

Take a look at the LinkCreationListener interface. You can implement one  
and contribute it to the LinkCreationHub service. A RequestFilter could be  
used to get the parameters from the query string and set the appropriate  
properties.

-- 
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor
Owner, software architect and developer, 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: Persisting state without HTTP Session

Posted by Jim O'Callaghan <jc...@yahoo.co.uk>.
Lutz,

Thanks for the response - Cookies would be a last resort - I don't want to be managing cookies and also feel it makes the app more breakable (fundamental state could be broken with browser security settings).  What I'm after is something akin to PageActivationContext but that passes the relevant object(s) using Request parameters rather than the querystring / url - thanks.

Regards,
Jim.

-----Original Message-----
From: Lutz Hühnken [mailto:lh.tapestry.list@googlemail.com]
Sent: 06 January 2010 13:50
To: Tapestry users
Subject: Re: Persisting state without HTTP Session


Cookies come to mind, would that be an option?


On Wed, Jan 6, 2010 at 2:16 PM, Jim O'Callaghan <jc...@yahoo.co.uk> wrote:
> Hi,
>
> Can anyone advise on the preferred way of persisting state between pages
> without using HTTP Session?  PageActivationContext using Object[] looks
> promising but I don't want long urls (from serialized objects) and there is
> more data to share than a defined number of keys - I'm looking for something
> that uses POST params ...?  Thanks.
>
> Regards,
> Jim.
>



-- 
altocon GmbH
http://www.altocon.de/
Software Development, Consulting
Hamburg, Germany

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


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


Re: Persisting state without HTTP Session

Posted by Lutz Hühnken <lh...@googlemail.com>.
Cookies come to mind, would that be an option?


On Wed, Jan 6, 2010 at 2:16 PM, Jim O'Callaghan <jc...@yahoo.co.uk> wrote:
> Hi,
>
> Can anyone advise on the preferred way of persisting state between pages
> without using HTTP Session?  PageActivationContext using Object[] looks
> promising but I don't want long urls (from serialized objects) and there is
> more data to share than a defined number of keys - I'm looking for something
> that uses POST params ...?  Thanks.
>
> Regards,
> Jim.
>



-- 
altocon GmbH
http://www.altocon.de/
Software Development, Consulting
Hamburg, Germany

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


Re: Persisting state without HTTP Session

Posted by Ulrich Stärk <ul...@spielviel.de>.
You might want to have a look at the "Clustering Issues" section of [1]. Tapestry already has some 
mechanisms built-in to help you with deciding when your session attributes have changed and need to 
be propagated to the other cluster nodes. Of course, keeping the amount of information stored inside 
the session to a minimum is always a good practice. E.g. use keys instead of serialized objects, etc.

Uli

[1] http://tapestry.apache.org/tapestry5.1/guide/persist.html

On 06.01.2010 16:36 schrieb Jim O'Callaghan:
> Ulrich,
>
> This is informative thanks.  Regarding avoiding using the session - it's not
> something I need to do at all costs - I am in the early stages of an
> application design and want to ensure the session usage is kept to a minimum
> as there may be a requirement to cluster at some stage - I had read that
> clustering applications that relied on session state had performance
> implications though perhaps if the amount of data retained in the session is
> small this is not going to cause too much of an overhead.
>
> Regards,
> Jim.
>
> -----Original Message-----
> From: Ulrich Stärk [mailto:uli@spielviel.de]
> Sent: 06 January 2010 15:06
> To: Tapestry users
> Subject: Re: Persisting state without HTTP Session
>
>
> I forgot that in order to store the object until the result page is being
> rendered, you'll need to
> somehow persist it. That would happen in the session again. So this is not
> an option for you.
>
> By the way: why do you want to avoid using the session at all costs?
>
> Uli
>
> On 06.01.2010 15:07 schrieb Jim O'Callaghan:
>> Thanks Ulrich.  Do you think it is realistic to have an entire application
>> use this approach as a method for sharing state between pages?, i.e. every
>> page is injected, or is there a downside to this?
>>
>> Regards,
>> Jim.
>>
>> -----Original Message-----
>> From: Ulrich Stärk [mailto:uli@spielviel.de]
>> Sent: 06 January 2010 13:58
>> To: Tapestry users
>> Subject: Re: Persisting state without HTTP Session
>>
>>
>> Use setters and the @InjectPage annotation.
>>
>> @InjectPage private MyPage resultpage;
>>
>> Object onActionFromSomeComponent()
>> {
>>      resultpage.setSomething(something);
>>      return resultpage;
>> }
>>
>> Uli
>>
>> On 06.01.2010 14:16 schrieb Jim O'Callaghan:
>>> Hi,
>>>
>>> Can anyone advise on the preferred way of persisting state between pages
>>> without using HTTP Session?  PageActivationContext using Object[] looks
>>> promising but I don't want long urls (from serialized objects) and there
>> is
>>> more data to share than a defined number of keys - I'm looking for
>> something
>>> that uses POST params ...?  Thanks.
>>>
>>> Regards,
>>> Jim.
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>

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


RE: Persisting state without HTTP Session

Posted by Jim O'Callaghan <jc...@yahoo.co.uk>.
Ulrich,

This is informative thanks.  Regarding avoiding using the session - it's not
something I need to do at all costs - I am in the early stages of an
application design and want to ensure the session usage is kept to a minimum
as there may be a requirement to cluster at some stage - I had read that
clustering applications that relied on session state had performance
implications though perhaps if the amount of data retained in the session is
small this is not going to cause too much of an overhead.

Regards,
Jim.

-----Original Message-----
From: Ulrich Stärk [mailto:uli@spielviel.de]
Sent: 06 January 2010 15:06
To: Tapestry users
Subject: Re: Persisting state without HTTP Session


I forgot that in order to store the object until the result page is being
rendered, you'll need to
somehow persist it. That would happen in the session again. So this is not
an option for you.

By the way: why do you want to avoid using the session at all costs?

Uli

On 06.01.2010 15:07 schrieb Jim O'Callaghan:
> Thanks Ulrich.  Do you think it is realistic to have an entire application
> use this approach as a method for sharing state between pages?, i.e. every
> page is injected, or is there a downside to this?
>
> Regards,
> Jim.
>
> -----Original Message-----
> From: Ulrich Stärk [mailto:uli@spielviel.de]
> Sent: 06 January 2010 13:58
> To: Tapestry users
> Subject: Re: Persisting state without HTTP Session
>
>
> Use setters and the @InjectPage annotation.
>
> @InjectPage private MyPage resultpage;
>
> Object onActionFromSomeComponent()
> {
>     resultpage.setSomething(something);
>     return resultpage;
> }
>
> Uli
>
> On 06.01.2010 14:16 schrieb Jim O'Callaghan:
>> Hi,
>>
>> Can anyone advise on the preferred way of persisting state between pages
>> without using HTTP Session?  PageActivationContext using Object[] looks
>> promising but I don't want long urls (from serialized objects) and there
> is
>> more data to share than a defined number of keys - I'm looking for
> something
>> that uses POST params ...?  Thanks.
>>
>> Regards,
>> Jim.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>

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


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


Re: Persisting state without HTTP Session

Posted by Ulrich Stärk <ul...@spielviel.de>.
I forgot that in order to store the object until the result page is being rendered, you'll need to 
somehow persist it. That would happen in the session again. So this is not an option for you.

By the way: why do you want to avoid using the session at all costs?

Uli

On 06.01.2010 15:07 schrieb Jim O'Callaghan:
> Thanks Ulrich.  Do you think it is realistic to have an entire application
> use this approach as a method for sharing state between pages?, i.e. every
> page is injected, or is there a downside to this?
>
> Regards,
> Jim.
>
> -----Original Message-----
> From: Ulrich Stärk [mailto:uli@spielviel.de]
> Sent: 06 January 2010 13:58
> To: Tapestry users
> Subject: Re: Persisting state without HTTP Session
>
>
> Use setters and the @InjectPage annotation.
>
> @InjectPage private MyPage resultpage;
>
> Object onActionFromSomeComponent()
> {
>     resultpage.setSomething(something);
>     return resultpage;
> }
>
> Uli
>
> On 06.01.2010 14:16 schrieb Jim O'Callaghan:
>> Hi,
>>
>> Can anyone advise on the preferred way of persisting state between pages
>> without using HTTP Session?  PageActivationContext using Object[] looks
>> promising but I don't want long urls (from serialized objects) and there
> is
>> more data to share than a defined number of keys - I'm looking for
> something
>> that uses POST params ...?  Thanks.
>>
>> Regards,
>> Jim.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>

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


RE: Persisting state without HTTP Session

Posted by Jim O'Callaghan <jc...@yahoo.co.uk>.
Thanks Ulrich.  Do you think it is realistic to have an entire application
use this approach as a method for sharing state between pages?, i.e. every
page is injected, or is there a downside to this?

Regards,
Jim.

-----Original Message-----
From: Ulrich Stärk [mailto:uli@spielviel.de]
Sent: 06 January 2010 13:58
To: Tapestry users
Subject: Re: Persisting state without HTTP Session


Use setters and the @InjectPage annotation.

@InjectPage private MyPage resultpage;

Object onActionFromSomeComponent()
{
   resultpage.setSomething(something);
   return resultpage;
}

Uli

On 06.01.2010 14:16 schrieb Jim O'Callaghan:
> Hi,
>
> Can anyone advise on the preferred way of persisting state between pages
> without using HTTP Session?  PageActivationContext using Object[] looks
> promising but I don't want long urls (from serialized objects) and there
is
> more data to share than a defined number of keys - I'm looking for
something
> that uses POST params ...?  Thanks.
>
> Regards,
> Jim.
>

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


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


Re: Persisting state without HTTP Session

Posted by Ulrich Stärk <ul...@spielviel.de>.
Use setters and the @InjectPage annotation.

@InjectPage private MyPage resultpage;

Object onActionFromSomeComponent()
{
   resultpage.setSomething(something);
   return resultpage;
}

Uli

On 06.01.2010 14:16 schrieb Jim O'Callaghan:
> Hi,
>
> Can anyone advise on the preferred way of persisting state between pages
> without using HTTP Session?  PageActivationContext using Object[] looks
> promising but I don't want long urls (from serialized objects) and there is
> more data to share than a defined number of keys - I'm looking for something
> that uses POST params ...?  Thanks.
>
> Regards,
> Jim.
>

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


RE: Persisting state without HTTP Session

Posted by Jim O'Callaghan <jc...@yahoo.co.uk>.
Thanks for the details Howard - I'll keep an eye on this one.

Regards,
Jim.

-----Original Message-----
From: Howard Lewis Ship [mailto:hlship@gmail.com]
Sent: 06 January 2010 18:44
To: Tapestry users
Subject: Re: Persisting state without HTTP Session


Something I'm hoping to put together as either a new tapestry5
project, or as a tapx project:

https://issues.apache.org/jira/browse/TAP5-53


On Wed, Jan 6, 2010 at 5:16 AM, Jim O'Callaghan <jc...@yahoo.co.uk>
wrote:
> Hi,
>
> Can anyone advise on the preferred way of persisting state between pages
> without using HTTP Session?  PageActivationContext using Object[] looks
> promising but I don't want long urls (from serialized objects) and there
is
> more data to share than a defined number of keys - I'm looking for
something
> that uses POST params ...?  Thanks.
>
> Regards,
> Jim.
>



--
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

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


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


Re: Persisting state without HTTP Session

Posted by Howard Lewis Ship <hl...@gmail.com>.
Something I'm hoping to put together as either a new tapestry5
project, or as a tapx project:

https://issues.apache.org/jira/browse/TAP5-53


On Wed, Jan 6, 2010 at 5:16 AM, Jim O'Callaghan <jc...@yahoo.co.uk> wrote:
> Hi,
>
> Can anyone advise on the preferred way of persisting state between pages
> without using HTTP Session?  PageActivationContext using Object[] looks
> promising but I don't want long urls (from serialized objects) and there is
> more data to share than a defined number of keys - I'm looking for something
> that uses POST params ...?  Thanks.
>
> Regards,
> Jim.
>



-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com

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


Re: Persisting state without HTTP Session

Posted by Olle Hallin <ol...@hit.se>.
I agree that one should try to defer session creation as long as possible.
But as soon as there is some state to persist, you shouldn't hesitate to use
sessions.

Session replication isn't necessarily a heavy thing.

Have a look at Terracotta, which shines at making web session replication
scale well.
Combine this with sticky sessions, and you get the best of two worlds.
Terracotta does only send replicated data to the nodes that actually demands
it.

See http://www.terracotta.org

Olle Hallin
Senior Java Developer and Architect
olle.hallin@crisp.se
www.crisp.se
http://www.linkedin.com/in/ollehallin



2010/1/7 Thiago H. de Paula Figueiredo <th...@gmail.com>

> Em Wed, 06 Jan 2010 13:36:31 -0200, Jim O'Callaghan <jc...@yahoo.co.uk>
> escreveu:
>
>
>  Thanks for the responses Thiago.
>>
>
> You're welcome!
>
>  I'll have a look at the
>> LinkCreationListener you suggested in your other email.  Regarding the
>> response below, does the approach not make an assumption that the objects
>> I am trying to share between pages  are persisted objects with a
>> key(id)/value elationship?  I'm using something at the moment that manages a
>> menu stack in the user's session and some other data that is really just
>> relevant to
>>
>> the user's session and not something I had thought of persisting.
>>
>
> The approach doesn't assume your objects have an id, but it does assume you
> won't put much information in the URLs. Internet Explorer, for example, has
> a limit of 2083 characters.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, software architect and developer, 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: Persisting state without HTTP Session

Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 06 Jan 2010 13:36:31 -0200, Jim O'Callaghan  
<jc...@yahoo.co.uk> escreveu:

> Thanks for the responses Thiago.

You're welcome!

> I'll have a look at the
> LinkCreationListener you suggested in your other email.  Regarding the
> response below, does the approach not make an assumption that the  
> objects I am trying to share between pages  are persisted objects with a  
> key(id)/value elationship?  I'm using something at the moment that  
> manages a menu stack in the user's session and some other data that is  
> really just relevant to
> the user's session and not something I had thought of persisting.

The approach doesn't assume your objects have an id, but it does assume  
you won't put much information in the URLs. Internet Explorer, for  
example, has a limit of 2083 characters.

-- 
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor
Owner, software architect and developer, 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: Persisting state without HTTP Session

Posted by Jim O'Callaghan <jc...@yahoo.co.uk>.
Thanks for the responses Thiago.  I'll have a look at the
LinkCreationListener you suggested in your other email.  Regarding the
response below, does the approach not make an assumption that the objects I
am trying to share between pages  are persisted objects with a key(id)/value
relationship?  I'm using something at the moment that manages a menu stack
in the user's session and some other data that is really just relevant to
the user's session and not something I had thought of persisting.

Your point regarding POST only working for forms and not links is relevant -
I had not considered this.

Regards,
Jim.

-----Original Message-----
From: Thiago H. de Paula Figueiredo [mailto:thiagohp@gmail.com]
Sent: 06 January 2010 14:40
To: Tapestry users
Subject: Re: Persisting state without HTTP Session


Em Wed, 06 Jan 2010 11:16:23 -0200, Jim O'Callaghan
<jc...@yahoo.co.uk> escreveu:

> Hi,

Hi!

> Can anyone advise on the preferred way of persisting state between pages
> without using HTTP Session?  PageActivationContext using Object[] looks
> promising but I don't want long urls (from serialized objects)

You don't need to serialize the objects: just add ValueEncoders to tell
Tapestry how it will get the id from a given object. This way, your URL
only has IDs, not whole objects. Anyway, is implementing a completely
session-less application viable? In any technology?

Using POST is complicated because it only works for forms, not links.

--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, 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


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


Re: Persisting state without HTTP Session

Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Wed, 06 Jan 2010 11:16:23 -0200, Jim O'Callaghan  
<jc...@yahoo.co.uk> escreveu:

> Hi,

Hi!

> Can anyone advise on the preferred way of persisting state between pages
> without using HTTP Session?  PageActivationContext using Object[] looks
> promising but I don't want long urls (from serialized objects)

You don't need to serialize the objects: just add ValueEncoders to tell  
Tapestry how it will get the id from a given object. This way, your URL  
only has IDs, not whole objects. Anyway, is implementing a completely  
session-less application viable? In any technology?

Using POST is complicated because it only works for forms, not links.

-- 
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor
Owner, software architect and developer, 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