Using Toplink with Servlets in a Clustered application server

Question

I am having some problems with Toplink.
Basically, I have a collection of HttpServlets that manipulate a domain object and its various collections of objects. The general technique is to place the domain object in the HttpSession, and have each Servlet modify this object by retrieving it, modifying it, and storing it when necessary. The problem is that since this application is running in a clustered environment, the object in the session may or may not be the same object returned from Toplink. It may be a serialized clone of the object from another server on the cluster.
This has caused several problems. First, if I am using indirction for the collections, when the domain object is deserializaed, it throws an exception when it tries to instantiate the indirection. Next, when trying to store the object, it is not registered with a unit of work, and I am not sure how to properly account for this. Third, there is a many to many relationship. The user may pick one such object, and add it to the domain object being manipulated. This seems to cause problems when the object is read from Toplink, and added to the domain object that is a serialized clone.
Anyway, my question is, what is the general pattern for handling an object being manipulated on a HttpSession in a clustered environment, where this object(s) may or may not be the actual objects returned from Toplink? My goal is to have a factory return one DatabaseSession per cluster server, and be able to load, store, and manipulate these objects in the HttpSession.
Here is an attempt at code:
import java.io.*;
import java.util.*;
import oracle.toplink.expressions.*;
import oracle.toplink.sessions.*;
public class DataAccess
private static Project project = new MyToplinkProject();
private static DatabaseSession session;
private UnitOfWork unit;
public DataAccess()
unit = getDatabaseSession().acquireUnitOfWork();
public ArrayList getAllCustomers()
Vector v = (Vector) session.readAllObjects(Customer.class);
return new ArrayList(v);
public Customer getCustomerForUpdate(Customer c)
Customer custCopy = (Customer) unit.readObject(c);
return (Customer) unit.registerObject(c);
public Form getCustomer(String id)
ExpressionBuilder builder = new ExpressionBuilder();
Expression exp = builder.get("id").equal(id);
return (Customer) session.readObject(Customer.class, exp);
public void saveCustomer(Customer cust)
unit.deepMergeClone(cust);
unit.commitAndResume();
private synchronized DatabaseSession getDatabaseSession()
if (session == null)
session = project.createDatabaseSession();
session.login();
session.setLog(new PrintWriter(System.out));
session.logMessages();
return session;
public void destruct()
release();
public void release()
unit.release();
session.release();
Anyway, from this code I hope you can see what I am trying to do. The basic idea is that a Customer object provided for store and update may or may not be a serialized copy. Also, the object returned from a read may be serialized before the indirction is attempted.
Thanks for any help,
Jason Wilson

Answer 1

Hi Jason
A single static DatabaseSession and a single static UnitOfWork is not the recommended way of working with TopLink from a servlet. Our recommendation is that you create a single ServerSession object and that every time a servlet needs to interact with a TopLink Session, the servlet first acquires a ClientSession from this ServerSession object and possibly acquires UnitOfWork from the ClientSession. A UnitOfWork is not intended to be shared by servlets, or by different clients.
Basically, what you're attempting to do with the DatabaseSession is something we would recommend that you do instead with a ServerSession/ClientSessions combination.
As for working with persistent objects that you store in an HttpSession, I will try to give you some relevant background. First off, the UnitOfWork is intended to be used to manage the changes to a set of objects in a SINGLE TRANSACTION. It is always much easier to manage if these transactions are short-lived (ie if there is one transaction per ServletRequest.
However, the fact that you are talking about storing objects in the HttpSession makes me think that you are also considering long-running transactions that are may be spread out over several ServletRequests. You should definately consider this decision very carefully. If you want to continually edit an object that is stored in the HttpSession, then we need to consider how to manage when the object's changes should be committed to the database and how to manage concurrency when two users have the same object in their respective HttpSession objects.
One idea is not to store the actual object in the HttpSession but instead to store the "id" of the object (something that you can use to find the correct object when the same user makes another request). So servlets always:
-acquireClientSession
-find the object that they are working with (based on information in the HttpSession)
-if the object is to be edited then a UnitOfWork provides clones of the object (this isolates you from changes that some other user makes to the same object)
-at the end, commit the changes to the object.
When the user makes another request, the object they read will have their changes. So, functionally, this is the same as storing the actual object in the HttpSession, except TopLink can provide proper ACID behavior for any updates that you decide to make. And don't worry about the added "expense" of having to query at the beginning of each servlet request; if you are storing the "id" of the object in your HttpSession, then you a simple cache hit is all that is required to get back the correct object. You don't have to go the database at all.
JIM