Reading through the transaction management chapter of the Spring 2.5 manual, here’s what it says about transaction propagation:
[N]ormally all code executed within a transaction scope will run in that transaction. However, there are several options specifying behavior if a transactional method is executed when a transaction context already exists: for example, simply continue running in the existing transaction (the common case); or suspending the existing transaction and creating a new transaction…
The manual then goes on to say
These settings reflect standard transactional concepts. If necessary, please refer to a resource discussing transaction isolation levels and other core transaction concepts because understanding such core concepts is essential to using the Spring Framework or indeed any other transaction management solution.
(Emphasis mine.) Hmm. Looks like I have some more learning to do!
Another nugget, this one from Section 9.5.3 Rolling back:
The recommended way to indicate to the Spring Framework’s transaction infrastructure that a transaction’s work is to be rolled back is to throw an Exception from code that is currently executing in the context of a transaction. The Spring Framework’s transaction infrastructure code will catch any unhandled Exception as it bubbles up the call stack, and will mark the transaction for rollback.
Offhand, this seems really good – if something bad happens I would expect there would be an exception involved, and it will be great if we don’t have to explicitly translate all those exceptions to whatever the transaction mechanism wanted instead.