I'm currently writing an application with a web front end which has a sequence of pages which populate a domain model, (in a wizard style).

After each page has been submitted the populated domain object(s) should be persisted to the database.

I'd like to avoid a database hit, when the user submits a page, but has made no changes to the domain model, for efficiency and auditing reasons.

Can anyone out there give me advice on the best way to accomplish this?

Currently I'm trying to use the session-per-conversation approach, as this allows me to let Hibernate manage the dirty checking, and only update actual changes to the database on calling merge(). If I use session-per-request, then HIbernate will always perform an update to the database on reattachment of the domain objects, even if no changes have been made.

Question is - is this the best approach? Should I still be using the session-per-conversation approach when I am having intermediate save-points which flush the session and obviously violate the atomicity of the transaction?

I think my session-per-request alternatives are:

1) Activate the select-before-update Hibernate feature to select the object and only update it if it differs - obviously this still invloves a hit to the database, (albeit less expensive), but there has been no update which satisfies auditing requirements.

2) Perform manual dirty-checking before deciding whether to perform an update or merge.

Any advice on this would be appreciated there doesnt seem to be much material on this, even though the Hibernate team recommended using long conversations in the original Hibernate In Action book.