Hibernate version:3

Name and version of the database you are using:Postgresql 8

I have recently migrated our project from Hibernate 2 to Hibernate 3. The problem I will describe exists in both versions. I believe that I am mis-using some capabilities in Hibernate, but cannot find the error of my ways. I have been through the posts in this forum (going back about 4 months) and have not found a clue. I have also read through both of the Hibernate Reference PDF documents and my trusty copy of Hibernate In Action. In addition, I have stepped through the souce code in attempt to discover where the error is. I say all this to point out that I have attempted to solve the problem myself, since I believe it is a mis-use issue. I need some help!

Our application requires that we collect audit information for each user. All changes must be tracked. This presented some challenges, but the interceptor seemed to be a natural solution for this. Using the examples on the Wiki, I created an interceptor that also contains the user's ID. That allows me to add entries into an audit table and capture the type of change, the user, the change and the timestamp. This requires a "session-per-user" and approach which also creates a separate interceptor per user session.

For deployment reasons, we are using RMI/IIOP for communication between the client and server. This adds an additional requirement for "shutting down" a business object when the user has finished using it. I created a base class for the business objects (Persistent.java) and added a shutdown() operation there that is overridden in the leaf classes. This operation will "cascade" the RMI shutdown through the associations much line the cascade in Hibernate.

The first problem that I encountered is that the changes that are required for shutting doen a remote object are being propagated to the database when flush() is called on the session. I have attempted to evict the persistent object prior to the flush, to prevent the shutdown changes from being written to the database, but this is not working. It appears that the next flush() of the session writes the changes to the database. We are using versioning, and even if I eliminate the changes, the version number of the object I am trying to remove is incremented.

I suspect that I am seeing a side-effect of the caching implementation. To confirm this, I changed the session approach to the "session-per-transaction" anti-pattern and executed the same code. In that processs, I saw that the changes were correctly written to the database when shutdown was called. Another problem appeared, the interceptor implementation did not contain a value in the previousState array.

This appears to be a "Catch-22" situation.

I need the cache to be populated so the previous value array in onFlushDirty() contains the previous value.
I can't have the cache populated, or shutdown() changes are flushed to the database.

There seems to be a relationship between the session, the cache and the interceptor that I am missing. Can someone offer suggestions on thie or point me to some additional reading?

Thanks in advance,
Gerry