Consider a multi-user service that provides primarily read-only access to data, and therefore caches objects. Update logic within this service must satisfy the following requirements:

1. Proposed changes are not available through the cache before the update has been successfully applied.

2. Changes are available through the cache after the update is successfully applied.

3. If an error is encountered on update, the cached object remains in its original state.

4. If the update is successful, all in-memory references to the cached object remain valid.

To satisfy these requirements, I believe the following design to be canonical:

1. Obtain the object from the cache.

2. Clone the object.

3. Populate the clone with validated input values.

4. Update the database using the values in the clone.

5. If the update succeeded, copy the values in the clone into the original object.

6. Discard the clone.

Hibernate does not support this design. I have seen the FAQ entry (Hibernate throws 'Another object was associated with this id'). I don't believe evict() is the solution. Is there some other way to accomplish these objectives using Hibernate?

regards,
Jay Dunning

Hibernate's process-level cache implements *exactly* this design!

Sorry, I forgot to mention something essential.

This design works only when caching is enabled. When caching is turned off, the update fails because the session is expecting the original object rather than the clone.

The architecture level where this logic occurs has no knowledge of whether caching is enabled. It shouldn't need to know--the pattern should be valid regardless of cache policy, even though it's overkill for the simple case.

I'm willing to do more work at the level where interaction with Hibernate occurs, but I don't see what could be done there.