CODEWITHSUNDEEP
javaspringhibernatetransactions
Matthias Wuttke
Matthias Wuttke

Reputation: 2032

Spring Hibernate transaction overhead

After upgrading Hibernate 3 to Hibernate 4, I am forced to remove HibernateTemplate from my spring based app. In order for a Hibernate session to be available, I have to use transaction demarkation more consistent than before. This requires me to add a transaction advice to my service layer as well as to pay close attention to background threads doing read-only database operations.

I have got two data sources (I have to use two different databases), the first one being used for nearly every application request, the second one used only for special (say, 1 of 1000) requests. Easiest thing is to use aspects to wrap both request types in transactions for both databases (I do not have to determine which requests need which databases), but I am wondering about the overhead involved in this. Is the actual database connection acquiring and transaction logic (like commit etc.) postponed until actual queries are performed? Or does my approach result in a lot of (in fact unused) transactions being started and committed?

To clarify, I have got two data sources, two transaction managers, two transaction advices for two (identical) "inServiceLayer" pointcuts.

Thanks for any help!

Upvotes: 2

Views: 1241

Answers (2)

Adrian Shum
Adrian Shum

Reputation: 40056

I am not considering the overhead in the first place, the biggest problem I can see here is your approach is fundamentally flawed. Assume some logic have access to DB-1 and DB-2, and after you committed in DB-1, and when you are trying to commit to DB-2, there is some problem happened and txn to DB-2 need to be rolled back, you will have inconsistent data in DB-1 and DB-2, as transaction in DB-1 has committed already.

Your case should be better utilizing distributed transaction (I wish both your DB are supporting XA), so you have only 1 (distributed) transaction to handle in your Spring point-cut. And, I believe (though I am not sure about it) normal XA transaction is not going to blindly create underlying transaction in all resources (i.e. underlying txn is created only when needed).

So, using distributed txn is giving you a more correct, concrete, maintainable and (probably) less-resource-wasting implementation.

Study further on your container on related setups.

Upvotes: 1

zagyi
zagyi

Reputation: 17528

What do you exactly mean on "use aspects to wrap both request types in transactions"? Your questions suggest that your application is not properly layered. You should have some kind of data access layer, where transactional logic is applied either declaratively (@Transactional) or programmatically (TransactionTemplate). Which would mean that requests that don't hit the database will never open a transaction.

Edit:
In case proper layering is not an option, you will certainly incur the overhead of transaction handling. The standard tools for transaction demarcation in Spring doesn't implement this kind of "lazy/on-demand" transaction initialization that you would be looking for. The easiest way to prove this is to enable debug/trace level logging on the transaction manager you use.

Upvotes: 1

Related Questions