We are using hibernate (currently 2.1.7 with CMT and WebSphere AS 5.1.x

We are not happy with the following statement within the 2. and 3.0 documentation:

11.2.3. Exception handling:
"No exception thrown by Hibernate can be treaded as recoverable."

Problem:

1.) more then one hibernate inserts and updates will be done during business functions within CMT-EJB calls.
2.) one insert or update will throw a SQL-Exception with duplicate key or optimistic locking reasons.

this is not an un-recoverable error for the business logic, because in some cases it should simply retry the update statements with some modified values, and it should still commit the business transaction including all other inserts and updates within the business-method.

Possible solutions:

a.) We could solve this by ending the cmt-transacion, which would rollback everything, and restart the whole CMT-transaction, re-executing the all inserts and updates. but we do not like this approach, because we would not do it this way with a plain jdbc-implementation.

b.) we could increase the db-locking to avoid some of the above conditions, but we do not like this approach either.

Without hibernate, these exceptions would be recoverable ?

thanks!

what we have done so far is this:

although we are working within a JTA Transaction we have tried to use multiple sessions.

this means we have closed the session just before executing the critital to be recovered sql statement, and closed it immediately again if any exception occours which should be recovered.

this seems to work, but we are not sure, if we are officialy allowed to do so.
furthermore we loose all caching effects for this JTA session.

can any hibernate team member please give us an official statement for this problem an how it should be handled propperly.

thanks.

is there anyone who can give us some official statement ?

Perhaps you should consider the complexity of rolling back 'object state'.