我正在阅读 services 上的 Grails 文档，其中多次提到事务/事务性，但没有真正定义 事务性 服务方法的真正含义。
鉴于服务的性质，它们经常需要交易行为。
这到底是什么意思？ transactional 方法只是那些使用 JPA/JDBC 与关系数据库通信的方法，还是它们适用于 JTA 涵盖的任何内容？
我有什么理由不创建服务类@Transactional，以防它发展到某天使用事务？换句话说，使所有服务方法都具有事务性是否存在性能问题？
【问题讨论】：
标签： grails service transactions jta
Grails 服务默认是事务性的 - 如果您不希望服务具有事务性，则需要删除所有 @Transactional 注释（包括 Grails 的 @grails.transaction.Transactional 和 Spring 的 @org.springframework.transaction.annotation.Transactional）并添加
static transactional = false
如果您没有使用 transactional 属性禁用事务并且没有注释，则服务的工作方式与使用 Spring 的注释进行注释相同。也就是说，在运行时 Spring 会为您的类创建一个 CGLIB 代理，并将代理的一个实例注册为 Spring bean，然后它委托给您的实际类的一个实例来执行数据库访问和您的业务逻辑。这让代理拦截所有公共方法调用并启动新事务、加入现有事务、创建新事务等。
较新的 Grails 注释与 Spring 注释具有所有相同的设置，但它的工作方式略有不同。不是触发单个代理的创建，而是在编译期间通过 AST 转换重写每个方法，本质上为每个方法创建一个迷你代理（这显然是一种简化）。这更好，因为数据库访问和事务语义是相同的，但是如果您从另一个使用不同设置注释的方法调用一个带注释的方法，则将尊重不同的设置。但是使用代理，它是委托实例内部的直接调用，并且代理被绕过。由于代理具有创建新事务或使用其他不同设置的所有逻辑，因此这两种方法将使用第一种方法的设置。使用 Grails 注释，每个方法都可以按预期工作。
事务性方法对性能的影响很小，如果有很多调用和/或大量流量，这可能会累积。在您的代码运行之前，会启动一个事务（假设一个未处于活动状态），为此，必须从池（数据源）中检索一个连接并配置为关闭自动提交，并进行各种事务设置（隔离、超时，只读等）必须进行。但 Grails 数据源实际上是“真实”数据源的智能包装器。在您开始查询之前，它不会获得真正的 JDBC 连接，因此在此之前所有配置设置都会被缓存，然后在实际连接上“重放”。如果该方法不做任何数据库工作（因为它从不做，或者因为它在数据库访问代码触发之前基于某些条件提前退出），那么基本上没有数据库成本。但如果确实如此，那么一切都会按预期进行。
但不要依赖此 DataSource 代理逻辑 - 最好明确说明哪些服务是事务性的，哪些不是，以及在每个服务中哪些方法是事务性的，哪些不是。最好的方法是根据需要对方法进行注释，或者如果所有方法都使用相同的设置，则在类级别添加一个注释。
您可以在this talk 中获得更多关于 Grails 交易的信息。
【讨论】：
首先，如果您的性能问题是由于您的服务是事务性的，那么您已经达到了必杀技。我之所以这么说，是因为在这成为主要（或什至次要）问题之前很久，您的应用程序中就会出现许多其他瓶颈。所以，不要为此烦恼。
在 Grails 中，transaction 通常与数据库连接或休眠会话的事务状态相关。虽然它可以是由 JTA 管理的任何东西，并具有适当的 Spring 配置。
简单来说，它通常意味着（默认情况下）数据库事务。
【讨论】：