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
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
ok up the
list each time it is needed from a service? If you find later that the
lookup is expensive, you could look at caching at the service level.
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/SelectModelImpl-Non-Serializable-Prevents-Session-Replication-in-Cl
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
Hello,
I'm working on clustering an application using Tapestry 5.3.3. Clustering is
accomplished by replicating the HttpSession to all nodes in the cluster. The
replication occurs by serializing the HttpSession. When the container attempts
to serialize the session a NotSerializableException is t
