I feel like I may be missing something. Due to hibernate's success I am sure that my thinking must be flawed, when it comes to this automatic dirty checking process.

I am using the Springframework with Hibernate 3, and I am using a SessionPerRequest pattern. So any object that I retrieve through load(),find(), etc... the object is in a persistant state, therefore any changes to an entities properties are automatically written to the database, cool huh!

Well not so cool if I want to have a validator validate the object before performing the update. Kind of like this:



The problem is that the information is already changed by the time validator is called. Should I be rolling back, if the validator says it isn't a valid client.

This seems like it would generate uneccessary SQL statements for validation that I can perform at the code level.

Any suggestions would be greatly appreciated. Thank you.

You could detach the object first using session.evict(cli), then reattach it afterwards using session.lock(cli, LockMode.NONE), but I am not convinced your design is sound. How come you can load an object, have the user perform changes, then save those changes back to the database all in one request-response cycle?

Well when the form gets submitted that is one request. If someone changes the name of a client on the form and then submits it I would have to get an instance of that client object in order to perform the changes.