Spring - Transaction Readonly

Just wanted your expert opinions on declarative transaction management for Spr开发者_Go百科ing. 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!

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.

A. Do I have to say 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?

Actually, you probably still want to run all of your get()s in the context of a transaction, to make sure that you are getting consistent reads. If on the other hand, you don't care about this, you can set the transaction level accordingly.

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

1. To help protect against errant writes within get()` methods
2. For optimization purposes. Not only can Hibernate make use of this information, as Bozho mentioned, but some databases/JDBC drivers can also be make use of this info.