"Serialize to the session" is a completely wrong statement
Nothing is serialized into the session, it is put in the session. and then
the application server
can serialize the session to other nodes or to disk or what ever.
If you have an standard app server and you don't have multiply nodes and you
don't restart
the server then normally the pages are never serialized that are kept in the
session

We do serialize the pages besides the session. And matej made some
optimizations that
when the server does cluster (serialize) that the page is only serialized
once and it tries
to reuse that byte instance.

johan


On 9/28/07, mchack <[EMAIL PROTECTED]> wrote:
>
>
> I am not sure I understand correctly. :)
>
> I thought the current page was serialized to the session and that the
> other
> pages or views were stored to the filesystem. So my question was really,
> if
> the filesystem where temporary pages are stored is shared, would Wicket be
> immune to requests coming in to random servers in the cluster. I was
> hoping
> that it might be possible to do a dumb load balancing arrangement. I am
> not
> totally clear on the whole page lifecycle, so hopefully my question is not
> completely out in left field.
>
> -Mike
>
>
>
> Matej Knopp-2 wrote:
> >
> > Hi,
> >
> > if I understand correctly, you want to disable page serialization on
> > session replication, as the filesystem where the page store stores
> > temporary pages is accessible from each node in cluster?
> >
> > There is a way to achieve it, just create your own page store
> > extending from DiskPageStore and make it implement the
> > SecondLevelCacheSessionStore.IClusteredPageStore interface. Just
> > implementing this interface will cause that the last accessed page
> > will not be replicated across cluster.
> >
> > -Matej
> >
> >
> --
> View this message in context:
> http://www.nabble.com/Clustering-Question---Can-the-2nd-Level-Page-Cache-be-shared-in-a-clustered-filesystem-configuration--tf4531607.html#a12933068
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to