Okay, please don't confuse this with an attempt to flamewar, I'm just curious.
During "regular" session replication what basically happens is that the modified session properties are serialized and sent across cluster to backing node(s). Now when this message is being sent, Wicket has already serialized the page to be stored in DiskPageStore and it uses the serialization data, so there is very little extra serialization done in clustered environment. After that the message is sent to the target node and deserialized. Against, most of the message is not really deserialized, it is just store in DiskPageStore (which is very quick). The only deserialized object is the Session object, which is usually couple of hundreds of bytes big. I'm really curious in which aspect Terracotta makes the clustering scale better. This is roughly the purpose of DiskPageStore. Wicket only keeps the last version of the last page instance in session. All previous versions/instances are stored on Disk. SessionLevelCacheSessionStore + DiskPageStore take care of this. There is a reason for not keeping the pages in memory. It's mostly to conserve session usage. Also the vast majority of pages kept in session store is never retrieved, as it only happens when clicking back-button or using application in multiple tabs/windows. So DiskPageStore is not a cache, even though lot of people confuse it with one. It's a storage for previous pages, and it's mostly write only. That said, I also don't see the point of holding previous page instances (even serialized) in HTTP session because the instances are rarely used. But maybe TC overflow to disk can do better job than diskpagestore and regular servlet containers, so I'm definitely not against having proper terracotta integration. -Matej On Mon, Jun 30, 2008 at 8:54 PM, Ari Zilka <[EMAIL PROTECTED]> wrote: > Well, > > Terracotta session replication is far more scalable, and easy to manage the > alternatives. > > That said, Wicket has the disk-based solution which I do not understand yet. > So I can't say if Wicket is better w/ disk or with TC, but my guess is with > TC because you can then share more than just Wicket state. You can do > Hibernate 2nd level cache, EHCache, and your own POJOs, all in the same > impl. > > So TC seems worth finishing up, no? > > --Ari > > On Jun 30, 2008, at 11:48 AM, Matej Knopp wrote: > >> Forgive me my ignorance :) >> >> I'm just still not sure what benefits does clustering wicket >> application with TC brings over regular session replication. And, is >> it not possible to setup TC to acts just like regular session >> replication (with serialization of modified session properties, etc.) >> >> -Matej >> >> On Mon, Jun 30, 2008 at 7:19 PM, John Patterson <[EMAIL PROTECTED]> wrote: >>> >>> Much appreciated! >>> >>> >>> richardwilko wrote: >>>> >>>> It does kind of work, If you use that class on my blog and dont have >>>> references to pages inside all other pages then things will probably be >>>> fine, assuming that the httpsessionstore doesn't cause you any problems. >>>> Our site is currently running at ~4500 active clustered sessions : ) >>>> >>>> Having said that I am making progress with the new session store and >>>> will >>>> probably have a tested version by the end of the week, depending on how >>>> busy I am. >>>> >>>> Richard >>>> >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Terracotta-integration-tp18168616p18200240.html >>> Sent from the Wicket - Dev mailing list archive at Nabble.com. >>> >>> > >
