Query on JTA and session.flush()

[Lakshmi Dasari]

I have a query on the usage of container managed transactions and explicit usage of session.flush(). From what I understand, if I demarcate a method boundaries with CMT Required option, then JTA takes care of associating the current session with the transaction, beginning, commiting the transaction and flushing and closing the session at the end of the transaction.

Now, if I have a method marked with CMT, which performs two DML operations, say session.save(object) and session.update(object), both
the statements are executed to the database at the time of transaction commit. This results in transaction rollback if any of the statements fail.
Now if I would like to handle the failure of one of the statements exclusively, I am unable to do so as JTA is flushing my session at the end of transaction. Meaning the exception is not caught in the try/catch block wrapping session.save().

Can I force the session.flush() after session.save() in CMT? This will force the statemets to be executed to the DB giving me the chance to handle the failure. I have seen that this works quite well for me. as I can explicitly rollback the transaction by setting sessionContext.setRollbackOnly() which rollbacks both the DML statements.

I want to know if there are any repercussions of handling session directly in CMT that I am not forseeing? Is it safe to call session.flush() in CMT?

[Mark Spritzler]

Why not just put it in a try-catch block?

Mark

[Lakshmi Dasari]

I have try/catch blocks in DAO around session.save and session.update, but the exception is not caught there as the focus shifts to where the transaction boundaries are marked. Because of this datalayer exceptions are exposed to the facade layer rather than the DAO layer.

[Mark Spritzler]

You can always throw the exception up out of the DAO layer. I suggest wrapping it up in a custom Exception, call it something like DAOException.

Mark

[Lakshmi Dasari]

The method which has the transaction boundaries marked is a session bean method. The exception is getting caught in the session bean methods instead of the DAOs.