When to use transactions in Spring with Hibernate?

Question

Upgrading my project I'm thinking here about transactions.
Well, the thing is I'm not quite sure when should I use the transactions for my Hibernate queries in Spring.
Not that I completely don't understand what transactions are, I guess I do, but
Do I need to use transactions for a get* type queries just setting the read-only attribute?

<tx:advice id="txAdvice" transaction-manager="transactionManager">
    <tx:attributes>
        <!-- all methods starting with 'get' are read-only -->
        <tx:method name="get*" read-only="true" />
        <!-- other methods use the default transaction settings -->
        <tx:method name="*" />
    </tx:attributes>
</tx:advice>

Is that efficient for get* queries?
Because, as far I think, using transactions should be done like for CREATE, UPDATE, DELETE and such queries.
Am I missing something here?

related https://stackoverflow.com/questions/13539213/why-do-i-need-transaction-in-hibernate-for-read-only-operations — Ahmed Nabil, May 27 '19 at 00:47

score 12 · Accepted Answer · answered May 13 '11 at 15:18

Using transactions is somewhat dependent on the requirement.

Obviously, using transactions on UPDATE and DELETE operations makes sense. Using transactions on SELECT statements could be useful too if, for example, you needed to lock the record such that another thread/request would not change the read. This would generally be a business requirement.

At our company we do wrap all statements (i.e. SELECT, UPDATE, DELETE) in a transaction.

In addition, transactional management is really better suited at another layer in addition to the data level. Generally, transactions would match the business requirement. For example, if the requirement is to deposit money in an account, then some higher level class/code should be used to mark the entire method as transactional since that specific method needs to be completed as one unit (since there would likely be multiple database calls).

Spring has much to say about transactional management.

I also normally wrap every business operation that accesses the database in a transaction. Recently I was wondering if this causes any overhead that might slow down the application. In such a case, would it make sense to use a transaction only for create, delete, update? — Giorgio, Mar 04 '12 at 18:30
Our company requires us to commit after every transaction, even SELECT statements. I could certainly see where wrapping only UPDATE statements would create less overhead. — tjg184, Mar 05 '12 at 13:18

score 3 · Answer 2 · answered May 13 '11 at 16:31

A good rule is to manage transactions at an application level above DAO. This way, if you have a data access operation A that some times need to be executed in own transaction and sometimes should join the existing transaction, you wouldn't have to jump through the hoops. Combine this approach with managing transactions (and Hibernate sessions) via AOP and watch your code grow more understandable and maintainable.

score 2 · Answer 3 · answered May 13 '11 at 15:14

2

This seems like a fairly decent answer of why you should. However, this gives some reasons not to. Basically, it you want to use them when data could end up in a bad state if your modifications are not completed.

answered May 13 '11 at 15:14

John Kane

4,383
1
24
42

score 0 · Answer 4 · answered May 13 '11 at 17:00

To answer your specific question about getters:

If you use an AOP transaction with readOnly true, and you properly set your JPA dialect to hibernate, Spring will put your Hibernate Session into no-flush mode. That can add up to substantial performance improvements for high volume operations by eliminating needless dirty-checks. So it is worthwhile in that regard.

When to use transactions in Spring with Hibernate?

4 Answers4