WebLogic & Session replication across clusters

I know I must have been asleep as I just found out today that WebLogic has an attribute value of replicated_if_clustered for the PersistentStoreType parameter.

WebLogic has a piece of functionality called In-Memory Replication that allows you to choose how HttpSessions are replicated across a cluster. Typical usage pattern is to enable this functionality in a clustered environment and you can have users failover from box A to box B when you take an outage on box A for upgrades, new releases or maintenance. This functionality worked great as you could stuff in serialized EJB handles in the session and have them replicated across cluster. When the user’s primary server went down, the load-balancer or web server directs users request to the backup server designated in the cookie. The backup server has the HttpSession information and can allow the user to continue. Any resource bound to server A that is serialized (EJB handles, etc) can be dynamically recreated and stuffed back in the session or handled appropriately on error.

This functionality worked great but setting the property to replicated in a standalone environment caused problems. And so your Ant script or whatever you used to build would need to know what environment if was building for and that’s ugly. Now using replicated_if_clustered, I can eliminate the ugliness of having the build script caring out what environment it’s building for. I wonder if anyone knows when this functionality was introduced? Please drop me a comment or email if you know.

WebLogic, HttpSession, replication, cluster

1 thought on “WebLogic & Session replication across clusters

  1. It’s been around since at least weblogic 6.1..it would help a little bit, but there’s still stuff that needs to go into weblogic.xml that could be environment specific. as well as the nightmare of confused responsibilities that is the startup scripts and config.xml.

    The offline scripting tool might add some relief here, but it’s still sort of a pain. I’ve had to separate “build” from “configuration” steps. So I build, which produces all of the files necessary to build a jar. Then I do a “configure” step, where all of the config files are generated from templates, and a tarball is produced that can be dropped onto the environment it was configured for. So the admin team has one file that controls their settings, and they feed it to the “configure” step to produce the tarball they need. Seemed like the least ugly way to split the concerns, but with some help from weblogic itself there’d be an easier way. (Something like .NET’s machine.config file heirarchy would be a great step).


Comments are closed.