I am currently working on introducing a session in view filter into an existing spring mvc application. In this application entity objects are often used as "form backing objects" So when editing some object typically the following happens

1) The object is loaded from the database based on its id.
2) Request parameters are bound to the object by using reflection.
3) Some rudimentary validation is done. If there are errors the form is redisplayed.
4) The object is handed of to some manager that may perform some additional sanity checks (is a user name unique etc).

Only after step 3 are any changes persisted to the database. However when I introduce the session in view filter, changes made to a persistent object will automatically be persisted even when validation fails.

Which does make sense but it is clearly not the desired behavior. So I am wondering how i should deal with this (i would assume) common scenario. I tried googling around for some time but did not find a lot of useful information.

Thinking this through I've come up with the following solutions

1) Use setSessionForm. eg. store the persistent entity in the session when rendering the form and use this (now detached) object in the onsubmit.

Concerns : If the session times out the there will be no detached object in the session on onsubmit and spring will create a new (persistent) object to handle the request.

2) Make a deep copy of the form backing object

Concerns : You would probably not want to do this by hand. I wonder if there are any generic solutions that are aware of lazy loaded relations

3) call session.evict after retrieving the object from the database.

Concerns : where would i put the evict method. Having manager.evict seems wrong.

Are there any other (preferably better) solution i did not list and if not which solution or combination of solutions should i pick and why