8.1 Declarative Transactions - Reference Documentation
Authors: Graeme Rocher, Peter Ledbrook, Marc Palmer, Jeff Brown, Luke Daley, Burt Beckwith
Version: null
Table of Contents
8.1 Declarative Transactions
h3. Default Declarative Transactions
声明式事务
Services are typically involved with coordinating logic between domain classes, and hence often involved with persistence that spans large operations. Given the nature of services, they frequently require transactional behaviour. You can use programmatic transactions with the withTransaction method, however this is repetitive and doesn't fully leverage the power of Spring's underlying transaction abstraction.
Services通常会包含这样的逻辑--需要多个domain类之间相互配合。因此它常常会出现这样的情况:涉及到的持久化包括大量的数据库操作。这些问题使得service中经常都需要对方法进行事务管理。当然你可以用withTransaction 方法来管理事务,但是这样很繁琐,也不能充分利用Spring的强大的事务抽象能力。Grails中可以对service进行事务划分,它声明service中所有方法都是事务型的。缺省所有的service都进行了事务划分。要禁用这个配置,只需要设置transactional 属性为false:
Services enable transaction demarcation, which is a declarative way of defining which methods are to be made transactional. All services are transactional by default. To disable this set the
transactional property to false:
class CountryService {
static transactional = false
}
You may also set this property to
true to make it clear that the service is intentionally transactional.
警告: 依赖注入是使声明式事务工作的唯一途径。如果你自己用new操作符,比如new BookService(),将不能得到一个事务型的service.
Warning: dependency injection is the only way that declarative transactions work. You will not get a transactional service if you use thenewoperator such asnew BookService()
Runtime 异常或Error时,将会自动回滚。事务传播级别默认是PROPAGATION_REQUIRED.Checked异常不会回滚事务. Groovy认为checked和unchecked异常非常相似,但Spring不知道这个道理并且使用默认值. 因此必须有了解checked和unchecked异常之间的差异。
The result is that all methods are wrapped in a transaction and automatic rollback occurs if a method throws a runtime exception (ie one that extends
RuntimeException) or an Error. The propagation level of the transaction is by default set to PROPAGATION_REQUIRED .Checked exceptions do not roll back transactions. Even though Groovy blurs the distinction between checked and unchecked exceptions, Spring isn't aware of this and its default behaviour is used, so it's important to understand the distinction between checked and unchecked exceptions.
Custom Transaction Configuration
Grails also fully supports Spring'sTransactional annotation for cases where you need more fine-grained control over transactions at a per-method level or need specify an alternative propagation level.Annotating a service method withIn this exampleTransactionaldisables the default Grails transactional behavior for that service (in the same way that addingtransactional=falsedoes) so if you use any annotations you must annotate all methods that require transactions.
listBooks uses a read-only transaction, updateBook uses a default read-write transaction, and deleteBook is not transactional (probably not a good idea given its name).自定事务配置
当你需要更细粒度的交易控制或需要指定另类传播级别的时候,Grails也支持Spring的 Transactional注释。
使用 Transactional注释会停用Grails对该Service的默认行为。所以如果你使用任何注释,你必须注解的所有方法
在这个例子中listBooks只使用只读的事务,updateBook使用一个读写事务,deleteBook不是事务性的(看它的名称这可能不是一个好主意)。import org.springframework.transaction.annotation.Transactionalclass BookService { @Transactional(readOnly = true) def listBooks() { Book.list() } @Transactional def updateBook() { // … } def deleteBook() { // … } }
Transactional= TRUE):
You can also annotate the class to define the default transaction behavior for the whole service, and then override that default per-method. For example, this service is equivalent to one that has no annotations (since the default is implicitly
transactional=true ):
import org.springframework.transaction.annotation.Transactional@Transactional
class BookService { def listBooks() {
Book.list()
} def updateBook() {
// …
} def deleteBook() {
// …
}
} listBooks方法重写为只读的交易:
This version defaults to all methods being read-write transactional (due to the class-level annotation), but the
listBooks method overrides this to use a read-only transaction:
import org.springframework.transaction.annotation.Transactional@Transactional class BookService { @Transactional(readOnly = true) def listBooks() { Book.list() } def updateBook() { // … } def deleteBook() { // … } }
updateBook和 deleteBook没有注明注释,它们继承了类级别的注释配置。如需详细资讯,请参阅Spring的用户指南Using @Transactional.Grails和Spring之间不同的特点是Grails使用Transactional时不需要任何先前的配置。Although
updateBook and deleteBook aren't annotated in this example, they inherit the configuration from the class-level annotation.For more information refer to the section of the Spring user guide on Using @Transactional.Unlike Spring you do not need any prior configuration to use Transactional; just specify the annotation as needed and Grails will detect them up automatically.
8.1.1 Transactions Rollback and the Session
Understanding Transactions and the Hibernate Session
When using transactions there are important considerations you must take into account with regards to how the underlying persistence session is handled by Hibernate. When a transaction is rolled back the Hibernate session used by GORM is cleared. This means any objects within the session become detached and accessing uninitialized lazy-loaded collections will lead toLazyInitializationExceptions.To understand why it is important that the Hibernate session is cleared. Consider the following example:class Author {
String name
Integer age static hasMany = [books: Book]
}Author.withTransaction { status ->
new Author(name: "Stephen King", age: 40).save()
status.setRollbackOnly()
}Author.withTransaction { status ->
new Author(name: "Stephen King", age: 40).save()
}save() by clearing the Hibernate session. If the Hibernate session were not cleared then both author instances would be persisted and it would lead to very unexpected results.It can, however, be frustrating to get LazyInitializationExceptions due to the session being cleared.For example, consider the following example:class AuthorService { void updateAge(id, int age) {
def author = Author.get(id)
author.age = age
if (author.isTooOld()) {
throw new AuthorException("too old", author)
}
}
}class AuthorController { def authorService def updateAge() {
try {
authorService.updateAge(params.id, params.int("age"))
}
catch(e) {
render "Author books ${e.author.books}"
}
}
}Author's age exceeds the maximum value defined in the isTooOld() method by throwing an AuthorException. The AuthorException references the author but when the books association is accessed a LazyInitializationException will be thrown because the underlying Hibernate session has been cleared.To solve this problem you have a number of options. One is to ensure you query eagerly to get the data you will need:class AuthorService {
…
void updateAge(id, int age) {
def author = Author.findById(id, [fetch:[books:"eager"]])
...books association will be queried when retrieving the Author.This is the optimal solution as it requires fewer queries then the following suggested solutions.Another solution is to redirect the request after a transaction rollback:
class AuthorController { AuthorService authorService def updateAge() {
try {
authorService.updateAge(params.id, params.int("age"))
}
catch(e) {
flash.message "Can't update age"
redirect action:"show", id:params.id
}
}
}Author again. And, finally a third solution is to retrieve the data for the Author again to make sure the session remains in the correct state:class AuthorController { def authorService def updateAge() {
try {
authorService.updateAge(params.id, params.int("age"))
}
catch(e) {
def author = Author.read(params.id)
render "Author books ${author.books}"
}
}
}Validation Errors and Rollback
A common use case is to rollback a transaction if there are validation errors. For example consider this service:import grails.validation.ValidationExceptionclass AuthorService { void updateAge(id, int age) { def author = Author.get(id) author.age = age if (!author.validate()) { throw new ValidationException("Author is not valid", author.errors) } } }
import grails.validation.ValidationExceptionclass AuthorController { def authorService def updateAge() { try { authorService.updateAge(params.id, params.int("age")) } catch (ValidationException e) { def author = Author.read(params.id) author.errors = e.errors render view: "edit", model: [author:author] } } }

