You want the session to be as lightweight as possible in order for it to be
easily replicated in a fault tolerant system.
With service/dao layer code I like to let the ORM (EJB/Hibernate) cache
whatever I need for performance. By keeping a cache of these objects in the
application layer and a reference for how to retrieve them in the session
(via an object's id) I get the best of both worlds.
So lets say I have a Member object that I use heavily and want to cache it
on the web/application server for performance reasons. In the user's session
I set the memberId. Now when the user requests something that needs the
Member object, I ask Hibernate to load the Member object and it will do so
from cache if it didn't expire.
If you have a cluster of servers and sticky sessions configured, the cached
items on a particular server will be tailored to those people on the server
because the sessions are sticky and they'll always be hitting the same
server. Now, if one of the servers go down, you can have your router or
whatever does the routing to the cluster redirect all requests for that
session to another server. If you were replicating the session to that other
server the user will fail over to that server and not notice an interuption
in the service. When a request comes to the new server to load(Member,
memberId) it won't have that Member cached, but it will retrieve it from the
database and cache it again.
It would be nice if Wicket could do something similar to this. I know you
can't do the same thing because in the example I shown the "Model" is just
an id pointing to a database record so it can be easily de/serialized from
anywhere, while a "Model" in Wicket is more complicated.
On 12/15/06, Nathan Hamblen <[EMAIL PROTECTED]> wrote:
Igor Vaynberg wrote:
> disadvantages being that fail over is harder unless the disk is shared
> between the cluster nodes. the disk can always be replaced by a database
> as well. the whole idea is relatively new and we have yet to explore its
> full potential.
Yes... that is kind of gutsy. I don't know how many people are actually
using replicated sessions across a cluster (my work uses cookie-stuck
sessions), but it's important to have that option. (The shared resource
cache is already a big hole in that support, right?) Seems like the best
thing would be for the servlet container to swap Serializable session
objects to disk on its own. Then we'd get the same benefit while using
the session normally. Do any servlet containers do that?
Nathan
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
