Hibernate version: 3.0
Database version: MSSQL2K
Background:
We have a DAO layer that does not expose a transaction API to the client. It must support both a hand-rolled DAO impl (no transaction abstraction on top) as well as Hibernate. Yes we could add the abstraction and expose the transactions but we do not wan the clients exposed to transaction management currently. We are relying on the underlying CMT JTA transaction in the app server for transaction demarcation. Yes -the DAOs will only work in a managed CMT environment. :(
Sample Usage:
Code:
<<session bean CMT>>
public void createUser(User newUser) {
UserDAO dao = null;
try {
dao = (UserDAO) DAOFactory.getDAO(UserDAO.class);
dao.open();
dao.create(newUser);
} catch (DAOException ex) {
log.error(ex);
..
..
} finally {
if (dao != null) dao.close();
}
}
Question:
In the above code you wil notice there is no calls to begin/commit the transaction. The container is doing that for us. Will hibernate work properly if the JTA transactions are started/stopped externally (no call made to session.beginTransaction())? The only worry I have is that hibernate may not have a way to "attach" to the current transaction since its started "behind its back". This could effect the flushing of the session on the session.close - how will it know to flush itself? I know that as long as the mods are flushed from the session JTA will handle the transactional aspects correctly.
If the above is true then one workaround I have is when my DAO is closed (dao.close()) I could explicitly flush the session at that point. What are the downsides to this if the client only calls close at the end of a transaction anyways?
Thanks,
Chris