Hibernate version: 3.2.4
Database: Derby

This issue unexpected for me (I'm not new to Hibernate), but maybe it is normal behavior. Hopefully someone here can tell me.

I am using JOTM as a transaction manager in a standalone application (with Hibernate).

I have a flow that essentially looks like this:

1) Client request comes in from SOAP -- start a UserTransaction.
2) Call SessionFactory.getCurrentSession() to get a session bound to the transaction.
3) Create a Criteria and query for an object, let's call it Foo.
4) Modify the Foo object in some way before sending it back to the client. Note however that the last interaction with Hibernate and the session is back in Step 3. We never call save(), or update(), or persist() or anything else with the modified Foo object.
5) In a 'finally' block in the SOAP servlet commit() the transaction. (In this case it should have been a read-only transaction, I thought).

When we execute the commit() in Step 5, Hibernate is generating an UPDATE to the database and updating the Foo object that we modified. This was surprising to me because no call was ever made to the session other than createCriteria() in Step 3. I assumed I was free to modify an object retrieved from Hibernate in any way I want and as long as I don't save() or update() it in some way then no harm no foul. Is that not the case?

The intent is to retrieve some objects, possibly make modifications to them "for the client's eyes only", and send them back over SOAP. I can't believe that the "solution" to this use case would be to somehow clone or copy the objects, modify the clones, and send those back to the client. I hope I'm wrong. Anyone?

Brett Wooldridge

if you dont want to fire update statement automatically then you need to make sure that within the transaction scope persistent entity is not changed.You could verify by logging just before commit and when this entitity came in transaction.Most of the casess it would be code side problem or some interceptor modifying some property.