Avoiding error about transaction attributes

[aaime]

Hi, I'm using Spring, among other, for declarative transaction demarcation.
This morning a colleage of mine had a problem, which turned out to be both a Hibernate collection mapping problem (I love those :-( ) and the fact that he named the service method in a way that the transation attributes did not intercept, that is, the method was named "clearPrivileges" but there was no "clear*" transaction attribute declaration in the transaction proxy.

Is there any way to make Spring cry out loud if it finds a method whose transaction attributes are not declared explicitly?

[rhasselbaum]

Is there any way to make Spring cry out loud if it finds a method whose transaction attributes are not declared explicitly?

That would be a nice feature. I don't think it's there. At my company, we use a default attribute of PROPAGATION_REQUIRED for all interface methods, which is usually appropriate. A developer can explicitly override it if she wishes, but otherwise, the default applies.

We get the "default" behavior using a parent bean template. If we need to override the transaction attributes in a child bean definition, we can, but we also make sure to add a PROPAGATION_REQUIRED attribute with a key of "*" to the end of the list as a fallback.

[Costin Leau]

Aaime you are using declarative transaction demarcation - that is you have to specifically declare your methods. For you it makes sense to wrap all methods inside transactions but not for everyone - I for example use PROPAGATION_SUPPORTS a lot since I don't want every hit on the db to be wrapped inside a transaction - reading is non-transactional, writing is transaction.

To solve your problem, as rhasselbaum suggested use the "*" regex which will include all your methods no matter what - you can use like a safety net anyways.

[aaime]

Hum, I'm using something a little different: PROPAGATION_FREQUIRED,read_only.

I guess the difference stands in the way things work: PROPAGATION_SUPPORTS does not open the transation, which means the connection will remain in auto commit, thus any change made to the database is made anyway.
PROPAGATION_REQUIRED,read_only on the contrary will open a transaction and will roll back it at the end, making sure you have made no modification whatsoever (provided that this is the method that opened the transaction).
At least this is what I have understood... feel free to correct me.

[Costin Leau]

It depends on your TransactionManager: snippet from TransactionDefinition API

Return whether to optimize as read-only transaction. This just serves as hint for the actual transaction subsystem, it will not necessarily cause failure of write accesses.

In my case I'm using Hibernate and thus the HibernateTransactionManager, I looked at the source and, if I understood correctly, on read-only mode the session is put on FlushMode.NEVER.
I guess with PROPAGATION_REQUIRED the transaction contract is respected but the changes are never flushed - thus your code is transactional and read-only.
I have seen a spread use of PROPAGATION_FREQUIRED,read_only but so far I couldn't justify it - I feel like I'm missing something here. For me it's seems overhead to open a transaction only to do reading - you are not touching the database anyways so why open a new transaction.
For the case where your method has to continue the current transaction you have PROPAGATION_SUPPORTS.

[steven.warren]

Hey costin,
Couple of comments, I agree with you that in the case of HibernateTransactionManager readOnly causes the session to be set to FlushMode.NEVER. However, that doesn't guarantee the database does not get updated. If someone calls flush manually, or if identity generation is used hibernate will write to the database regardless of the session flush mode.
Also, the readOnly hint does not effect commit/rollback. If you want to ensure no changes go to the database, you need to be in a transaction and make sure it's rolled back (one of the reasons to use PROPAGATION_REQUIRED, or even PROPAGATION_REQUIRES_NEW).

[Costin Leau]

Good points. Wrapping a transaction around the readOnly method does act like a safety net.

If someone calls flush manually

That someone should wrap it's method inside a transaction - after all it's write access to the DB. However, I agree with you that in case (s)he hasn't, you won't have the DB compromised.

identity generation is used hibernate will write to the database

I'd like more details on this matter; AFAIK identity generation forces two queries to the database, one for getting the ID from the DB and one for writing the actual object to the database with the new identifier.
However, this happens only if you want to save an object that has an generated identity key - with FlushMode.NEVER, the object will never reach the DB (I don't know about the call to get the new identity).

[steven.warren]

AFAIK, and have seen, when you call hibernate's save function, a row is immediately inserted into the object's database table with the primary key (either you provide or it get's generated). I don't believe this is related to the flush mode in any way.