Existing Object Won't Update

Question

I have a Toplink/JSF application, and am having trouble modifying objects that are already stored in the database.
Here's a scenario:
1) Objects are read with a session.readAllObjects call. A JSF data table displays those objects.
2) The user selects one of the objects in the data table. Upon pressing a "Choose" button, the chosen object is placed into a field called "chosenInstance" on a "backing_home" bean. This bean has session scope.
3) The user can then navigate to various JSF pages. Each page displays the object and some of its related objects.
4) The user can update data on a page. The JSF page binds af:inputText fields to the object stored in the backing_home bean like this: #{backing_home.chosenInstance.description}
5) The user then presses the Save button. The action references the backing_home bean field, which has been now updated by the JSP, and ultimately issues the following method:
public Object persist(Object entity) {
UnitOfWork uow = getSessionFactory().acquireUnitOfWork();
Object existingObject = uow.readObject(entity);
Object returnInstance = null;
if (existingObject != null) {
uow.deepMergeClone(entity);
returnInstance = existingObject;
} else {
returnInstance = uow.deepMergeClone(entity);
uow.commit();
return returnInstance;
Unfortunately, this method never updates objects. As soon as the "uow.readObject(entity)" line exectues, the existingObject and the entity object are the same object.... so the uow.commit() line never executes any sql to the database... since it thinks no data has changed.
In a simple test case for the above persist method, the method works ok. Is there something about my steps 1-5 that could be messing up my ability to persist object changes?

Answer 1

Sounds like your application is modifying the objects retrieved from the session in step 1. Users should never directly modify these as they are from the shared session cache. When you eventually acquire a UnitOfWork and merge, it uses the objects in the shared cache to build a clone for comparison purposes, which is why it doesn't find any changes.
Step 1 either needs to read from a UnitOfWork (and so operate on working copies), or clone the results returned from the session.
Best Regards,
Chris