Question

Just wanted your expert opinions on declarative transaction management for Spring. Here is my setup:

1. DAO layer is plain old JDBC using Spring JdbcTemplate (No Hibernate etc)
2. Service layer is POJO with declarative transactions as follows –
   save*, readonly = false, rollback for Throwable

Things work fine with above setup. However when I say get*, readonly = true, I see errors in my log file saying Database connection cannot be marked as readonly. This happens for all get* methods in service layer.

Now my questions are:

A. Do I have to set get* as readonly? All my get* methods are pure read DB operations. I do not wish to run them in any transaction context. How serious is the above error?

B. When I remove the get* configuration, I do not see the errors. Morever, all my simple get* operations are performed without transactions. Is this the way to go?

C. Why would anyone want to have transactional methods where readonly = true? Is there any practical significance of this configuration?

Thank you! As always, your responses are much appreciated!

Answer 1

This post tells that the behaviour or the readOnly flag is persistence-mechanism-dependent.

C. Yes, when using hibernate, it gives performance benefits by setting the flush mode to FLUSH_NEVER (as described in the linked post)

B. Yes, JDBC calls do not require a transaction (hibernate requires one), so removing the @Transactional configuration trims all transaction management.

A. I’d assume spring is calling connection.setReadOnly(true) but your JDBC driver doesn’t support this

The bottom-line is : don’t use readonly transactions with plain JDBC.

And another thing – transactions are supposed to span multiple queries. Don’t make your transactions too fine-grained. Make them a unit of work.