Hi, session is something that lives on server side, so there's no chance to persist it on client. Besides, client solutions like cookies and localStorage have size limits. What you should try to do is to adopt a third solution that makes session clustering possible without needing stickiness. For example Apache Ignite:
https://apacheignite-mix.readme.io/docs/web-session-clustering If you go for such kind of solution you should also choose to save page instances directly into HttpSession, so everything can be cached into Ignite: https://ci.apache.org/projects/wicket/guide/8.x/single.html#_httpsessiondatastore On Wed, Jul 3, 2019 at 11:15 AM Bergmann Manfred <m...@software-by-mabe.com> wrote: > Hi. > > I know a few points, like using LoadableDetachableModel’s to keep session > size low. > As it has to be replicated in some way between server nodes in a cluster, > or stored in a database. > Session stickiness is probably how most deployments work. > > But what about offloading the session into one or more cookies (which are > encrypted) and such. > Is that something that is actually being done in practice? > It basically would not require session replication in the background and > could work without session stickiness. > > Session size. In middle sized web applications with a JavaScript enabled > components. > Or actually generally, what is a session size that is ideal, or good to > replicate? > > What is your experience? > > > > Regards, > Manfred > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Andrea Del Bene. Apache Wicket committer.