views:

190

answers:

2

Hello Gurus! Just wanted your expert opinions on declarative transaction management for Spring. Here is my setup - A. DAO Layer is Plain old JDBC using jdbcTemplete (No hibernate etc) B. Service Layer is POJO with declarative trasnactions 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 -

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?

B. When I remove the get* confiiguration, 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 resposes are much appreciated!

+1  A: 

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.

Bozho
Thank you Bozho! Clear as day. I guess I will remove the get* configuration as I am using plain JDBC.
AAK
+1  A: 

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.
matt b
Thank you Matt! I guess my get* methods are pretty much simple independant SQL select queries and I am not using Hibernate, so I'll turn off the setting.
AAK