I have gone over the documentation at great length related to the use of the Hibernate Transaction for a Session and I'm confused about the intent and use of the Transaction. Forgive me if i'm a little slow on the uptake, but help me out.

I believe that i've read that using Transaction demarcation is strongly recommended for performance reasons. It helps to accumulate DB requests and limits access to the DB. I've also read that it is tied to an underlying jdbc transaction.

I also understand that Transaction provides atomicity (among a few other things) but specifically the ability to rollback request to the beginTransaction() call or commit() it if all goes well.

Okay, sounds good to me.

These 2 problems are valid but i feel like one may want one and not the other. Specifically performance without atomicity.

But it appears to me that they are both gotten through the use of Transaction and i'm only allowed (understandably) one uncommitted transaction on the session.


I've tried to solve this by designing and building a small framework as described below.

It uses the Session per Request Thread Local Pattern.

I have, within our application, been able to isolate a thread of execution similar to examples related to Servlet.

Beginning of thread creates the Hibernate Session for the thread. It also "currently" begins a transaction for this session, think of it as the thread transaction or the implied transaction. (Performance drivien)

The thread then can do any number of things and interact with our DAOs. Some of this activitity may be unrelated. Our request does alot of work. The DAO's do their thing using the Session, write/load etc, but do not commit.

When the thread exits, a call is made to commit the session transaction. Please understand, that I am doing this NOT because i want to be able to rollback under certain circumstances, but that i want to ensure that Hibernate minimizes access to the DB. Performance reasons.

At the same time there may very well be 2 or 3 DAO calls that i truly want to place in a Transaction such that they either all succeed or fail as a unit. It's clearly up to portions of the thread and what they are trying to accomplish.

Both of these scenarios live and can happen in the thread of execution..

Currently I do the following to try to accomodate both.

1) I create what i would call an implicit Transaction when the session is opened transparent to the DAOs.
2) DAOs never begin or commit Transactions
3) Commit is done at the end of a thread not by any one DAO.

4) Additionally, I've added a cross DAO helper method that can explicitly begin a transaction to accomodate a need for all or nothing scenario or what you might call a "business transaction"

5) Since there can only be one outstanding Transaction on a session, when one of these is started, the implied (thread) transaction is committed. The Business Transaction then takes over and eventually is either committed or rolled back by exposing those 2 Helper calls. We only allow one of these at any one time.

This, at first, seems to solve all my problems. I get a Transaction that lives as long as the thread, implicitly. I also allow users of the DAOs to create their own Transaction across calls to several DAOs.


Does this make sense? I fear that these 2 transactions will not coexist.

i guess the bottom line question is this. What if what i want is performance by minimizing touching the database but not atomicity?

What happens in Hibernate if i do not use Transaction? I've read that performance is not good, and the way to get performance is to use Transaction.

A somewhat clear description of how these 2, not necessarily same goals, are attained without impacting each other would be real helpful to me.

Most of your conclusions (I stopped in the middle) are incorrect. Start again, and consider "Transaction" to be a wrapper around JDBC or JTA transactions, nothing else. A Transaction.commit() also flushes the Hibernate Session (this is called transactional write-behind, keeping database locks as short as possible). JDBC, JTA and flushing are well documented, there is nothing else that would be worth talking about if you think "Transaction API".

Thanks much for the quick response.



This is where i did start. I did assume that Transaction is a wrapper around jdbc's transaction. But then much of the rest of the Hibernate documentatin at least "implied" to me that you get write-behind and performance only by using Transaction. Please just confirm that this is one of my "wrong assumptions"

If so, then if i do not use Transaction at all i will still benefit from Hibernate's "write-behind" capability, and that only when i truly want a Transaction for purposes of commit/rollback is when i use it and it will, in turn, utilize JDBC's transaction object.

thanks again

Flushing gives you write-behind, not Transaction.