Featured White Papers

• Java Web Hosting | DailyRazor.com - Over 10yrs Of Java Web Hosting Exp!

Sponsored Links

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Manage distributed sessions

To avoid a single point of failure, use a distributed architecture for managing sessions

By Kelly Davis and Robert Di Marco, JavaWorld.com, 04/13/01

Another possibility for multiserver session management utilizes the JavaSpaces API (for documentation, see Resources) to maintain records of the session objects. However, if the machine hosting the JavaSpace were to go down because of crashing or maintenance, all session information would be lost. So again, we are left with a single point of failure.

To accomplish the distributed session server with n-nodes, we must address three main problems:

1. How to set up a repository to store session information
2. How to synchronize distributed repositories
3. How to let a servlet server retrieve the session information in such a way that if one repository suddenly goes offline, it tries to retrieve the object from the next repository

Introduction to the Mnemosyne

The repository we will use to store the session information is an implementation of the Mnemosyne interface (named after the Greek goddess of memory and mother of the muses). An object that implements Mnemosyne is responsible for managing all objects in the repository. Any other object that wants to write, retrieve, or remove objects in the repository must call a method of the Mnemosyne.

To be saved to a Mnemosyne, an object must implement the Memory interface, which defines the equalsMemory()operation for determining whether two memory objects are equivalent. That allows the Mnemosyneto figure out what object should be returned on a read or a take request. The Memory interface also extends Serializable so that you can use RMI to transmit the object across the network.

A Mnemosyne uses three other interfaces to represent its state:

1. A CommonContext interface will store all information for the Mnemosyne. Each Mnemosynewill have one instance of a CommonContextobject to allow for synchronization between methods when reading, writing, and taking Memoryobjects. For writing and taking, the CommonContextdefines both "silent" and "loud" methods. The silent methods are used when objects need to be added without any event notifications. For example, when a Mnemosynereceives a WriteRemoteEvent (a notification that an object has been written to a remote Mnemosyne), it will want to write another object to the CommonContext. However, it doesn't need to notify the other remote Mnemosynes; the original Mnemosynehas notified them. So the write is done "silently" by calling the CommonContext's silentWrite()method. The "loud" methods give details of the event to any interested listeners that are called when an object is first put into the context.
2. A Transaction interface allows for distributed transactions when reading, writing, or taking Memoryobjects. That means multistep operations can occur on the Mnemosyne.
3. A TransactionContext interface manages a distributed transaction. That makes it possible to abort or commit transactions.

Keeping Mnemosynes synchronized is accomplished with two methods defined by the Mnemosyne: synchronize()and notify(). synchronize()is intended to get a local Mnemosyne"in sync" with a Vector of other Mnemosynes. (Those Mnemosynes may be local or remote, but for the sake of clarity, we will assume they are remote.) A sample implementation of the synchronize()method (from the MnemosyneImplclass) is displayed below. (See Resources for the complete sample code to this article.)