You should read this:
http://tapestry.apache.org/performance-and-clustering.html
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/SelectModelImpl-Non-Serializable-Prevents-Session-Replication-in-Cluster-tp5720280p5720286.html
Sent from the Tapestry - User mailing list arch
bject: RE: SelectModelImpl Non-Serializable Prevents Session Replication in
Cluster
You should remember that HTTPSession usage should be kept to a minimum,
especially in a clustered environment. HTTPSession usage doesn't scale well.
Do you really need to persist a list in the session? Could y
You should remember that HTTPSession usage should be kept to a minimum,
especially in a clustered environment. HTTPSession usage doesn't scale well.
Do you really need to persist a list in the session? Could you instead just
store a user id (or other filter parameter) in the session and look up the
t: Re: SelectModelImpl Non-Serializable Prevents Session Replication in
Cluster
On Thu, 28 Feb 2013 13:19:31 -0300, Steve Wall
wrote:
> Hello,
Hi!
Don't @Persist or @SessionState SelectModel. That's a bad idea. As Lance said,
if you really need to persist it somehow, persist a
On Thu, 28 Feb 2013 13:19:31 -0300, Steve Wall
wrote:
Hello,
Hi!
Don't @Persist or @SessionState SelectModel. That's a bad idea. As Lance
said, if you really need to persist it somehow, persist a List that is
used to create the SelectModel, not the SelectModel itself.
--
Thiago H. de
Is it your custom code that is @Persist ing the SelectModel? If so, you could
@Persist the underlying Collection instead and build the SelectModel in the
UI each time.
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/SelectModelImpl-Non-Serializable-Prevents-Session-Replic
