DI Required for Declarative Transactions

[D]ependency injection is the only way that declarative transactions work. You will not get a transactional service if you use the new operator such as new BookService()

http://grails.github.io/grails-doc/2.3.11/guide/services.html

Transactions are a Business Concern

Transactions are not a persistence concern, they're a business concern. As such, DAOs shouldn't be transactional, your service layer should be.

- Barney http://www.briankotek.com/blog/index.cfm/2008/1/11/Thoughts-on-Adding-Nested-CFTRANSACTION-Support-to-ColdFusion

...typically you want service method to behave transactionally instead of just DAO methods - if you have 2 updates in service method and second one fails, transactions don't help you to have DB consistent (but it depends on your business logic)

- Betlista http://stackoverflow.com/q/10298483

Update: Unrelated but the notion that "business concerns" or "business/domain logic" belongs in a "service layer" may boil down to semantics that are directly dependent on architectural style chosen, e.g. SOA vs DDD (see discussion at http://programmers.stackexchange.com/questions/218011/how-accurate-is-business-logic-should-be-in-a-service-not-in-a-model).