At work we are using hibernate 3.2.2ga and I'm wondering what are the alternatives to select-before-update? We have an issue with a to-many relationship where a transaction commit takes forever as more objects are added to the too many side of the relationship. This is more than likely caused by the select-before-update that it's doing when it queries one select at a time ever single object back on the to-many side.

I'm aware of alternatives such as keeping the original state or snapshot of the object around in memory or making use of a version field or timestamp.

Are there alternatives to select-before-update in releases of hibernate since 3.2.2ga?

You could merge your root object before updating it. If you want all referenced objects to be merged, you can either set fetch-strategy to eager, or even better use CascadeType.MERGE, so that the merge-operation is cascaded to the relationship.

Maybe enabling batch-fetching is also a solution, but I am not sure in this case. To enable batch-fetching you have to enable it via hibernate-configuration (set hibernate.jdbc.batch_size and hibernate.default_batch_fetch_size).

So you're saying that when you do the merge operation I wouldn't be incurring overhead I'm already incurring with select-before-update?

We use ehcache but our Session open/closes all the time and I assume this rules on lazy fetching with ehcache. I'm curious as to why ehcache cannot reattach the object with the session.

I think if you use merge, the whole collection of the toMany-relationship is going to be fetched in a single statement instead of selecting each entry. But I am just guessing, have you tried it? Also, you should try to enable batch-fetching.