it is not a question about storing the entire session or not. The idea is that the second level cache keeps the session small. Because if we just rely on the session to serialize by the container then how many pages or page versions should we keep in memory? we did see by the AccessStackPageMap which defaults to 7 that they can grow quite large on big pages that are also changing a lot.
and also saving just the page is much less then serializing the complete session for sure if we have that 7 page/versions in by default. the problem is that we are trying to find a balance between session usage and speed. We are still tweaking the Serialization and FileStore implementation as for clustering, i don't think that is a big problem, sticky session is the way to go anyway (i don't believe in the none sticky session variant at all, thats doesn't gain you anything) And then only in the situation where one server goes down and you have a failover AND the next request of a client is the backbutton. Then they will get a page expired They didn't loose the session info, or the current pages of all the current pagemaps only the old pages if you don't share the directory over all the servers. But i don't know if that really gains you anything.. You could drop in a DB save implementation ofcourse if you really need it. johan On 2/19/07, Ryan Holmes <[EMAIL PROTECTED]> wrote:
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. 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)? 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. 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? 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. 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). 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? 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. Thanks, -Ryan
