Hi Wicket devs, Sorry for jumping in on this list since I'm barely a Wicket user (much less a developer), but I wanted to share some thoughts/ questions regarding your work on the SecondLevelCacheSessionStore.
That's always very welcome. I'm about to start a discussion on it myself actually; there's been quite some talk about it on IRC, but it is time now for a larger audience and better history (mailing list). Keep in mind that the SecondLevelCacheSessionStore (SLCSS) is still experimental and that not all of Wicket's committers agree just yet that this is the best default nor that it's current implementation is the best. But we have some working code, which is great for discussion. Also keep in mind that we want to support both mechanisms (the 'old' totally RAM based and this new one) and any mechanisms people use for themselves.
1) If the main purpose is to move sessions out of RAM and onto disk or a database, aren't you largely duplicating functionality already (and probably more appropriately) provided at the container level (e.g. Tomcat's PersistentManager)?
The idea of having a custom implementation is that we can (potentially at least) optimize it for just Wicket, and have a mechanism available that should work regardless of the app server you are using (and the bugs that might be in there)
I realize that SecondLevelCacheSessionStore moves only part of a session out of memory rather than the whole thing and so, in effect, keeps the literal session size small. But why is it necessarily better to swap a part of every session in and out of RAM vs swapping entire idle sessions out of RAM and back in only when needed (this is PersistentManager's strategy)? It seems like the PersistentManager approach would be more efficient (less disk writes) and should provide similar RAM savings in the long run.
More efficient when it comes to disk writes, but not when it comes to using RAM. We can clean up RAM quicker and thus need less RAM per session in the short run. And the short run is better for handling peaks.
2) Doesn't the SecondLevelCacheSessionStore create another data repository that must be shared or distributed across clustered application servers? I mean, in addition to normal session clustering wouldn't one also have to cluster whatever gets persisted by SecondLevelCacheSessionStore since it stores data that is essentially an extension of the session?
Yeah. This is something that we are still discussing. For starters, it depends on whether you work with session affinity (aka sticky sessions). If that is the case, this approach works fine. However, if you don't and/ or want a backup without having to use a shared network disk, I believe the file based approach isn't great.
3) I'm afraid that a file based session store (the default implementation, I believe) will actually perform so badly that it won't be useful in the type of high load environment SecondLevelCacheSessionStore is intended to address.
Sorry for being a smart ass, but the big mistake people always make in matters like these - Wicket developers included - is make assumptions without actually calculating and testing them. And there also isn't a 'bad' approach by default here, as what works well depends entirely on what the traffic looks like.
In my experience with a fairly high traffic PHP site, file-based session storage is extremely slow and you have to switch to a database-backed solution to handle any kind of serious load (assuming that you can't hold the sessions in RAM, which is basically not an option anyway with PHP).
Maybe. Keep in mind we're writing in a non-blocking low priority background ground thread (or at least, that is the idea) and we'll only be reading from second level storage if the requested resource (page) isn't available in the first level cache. And as we always hold at least the first the current page in memory, and that is the page that is used to resolve requests from forms and non-bookmarkable link components etc, in practice, the second level storage is only accessed for back button requests, for which you may argue that they'll be far less common than normal requests (although even here, if you are serious about your stuff you might want to collect statistics about back button use and configure accordingly when that is possible).
I know a database implementation of SecondLevelCacheSessionStore has been discussed, but I guess what I'm trying to point out is that the default implementation may actually perform and scale worse than no SecondLevelCacheSessionStore at all would. Furthermore, if a database- backed solution works well, why not just let the container store entire sessions in a database and avoid adding a second layer of session storage that must be managed in a cluster?
If you depend on a cluster being managed by your app server, the old approach might be the best for you anyway. But if you are e.g. using Terracotta - which we plan to use for the day time job I'm working on, and which seems like an excellent match - it doesn't matter where the data lives that needs to be clustered. We (and our users) have also quite a few options left when it comes to triggering that clustering. For app servers this is done by putting attributes in the HttpSession object. When exactly you do that is part of the ISessionStore implementation, and can thus be tweaked and optimized to your liking. In fact, this is an area we should look at for this new second level cache thing as well (btw, it's just a working name and I hate the name for it's verbosity).
I apologize if these questions/suggestions are ignorant or come across as rude. I certainly don't mean to disparage anyone's efforts in making Wicket more scalable and I don't pretend to be a scalability guru (although I do have a decent amount of experience in this area that I'll be glad to talk about if that's useful). I was just reading through some of your past discussions about SecondLevelCacheSessionStore and I couldn't help but see a few red flags.
No, not at all. Please discuss. I hope I cleared things up a bit - and other devs please chip in. It's open source, so the more people think with us, the better we can make it. Cheers, Eelco p.s. I'm sending a proposal for discussing the specs of this thing hopefully later this evening.
