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
- Questions about SecondLevelCacheSessionStore Ryan Holmes
-
