在Spring 3 / Hibernate中回滚事务的最佳实践 [英] Best practices for rolling back transactions in Spring 3/Hibernate

问题描述

引用 Spring文档：

任何RuntimeException将触发回滚，并且任何检查的异常不会被执行

引用 javapractices.com

未检查的异常：

• 代表程序中的缺陷（错误） - 通常无效参数
  传递到非私人方法。来自Java编程
  语言的
  引用，由Gosling，Arnold和
  Holmes说：未经检查的运行时异常
  表示一般情况下
  表示反映错误的条件您的
  程序的逻辑，并且不能从运行
  时合理地恢复
  。


• 是RuntimeException的子类，通常实现
  使用IllegalArgumentException，NullPointerException，
  或IllegalStateException


• 方法没有义务为其实现抛出的未检查异常
  建立策略（并且它们几乎总是不）
  
  
  检查异常：
  
  
  
  
  • 在
    程序（无效用户输入，
    数据库问题，网络中断，
    缺少文件）的直接控制之外的区域中表示无效条件
  
  
  • 是异常
  
  
  • 的一个方法所必须的子类为其执行所抛出的所有已检查的异常
    建立一个策略（
    将检查的异常进一步传递给堆栈中的
    ，或者以某种方式处理它）
  
  
  
  

如果在我的业务逻辑中发现问题，并且想要回滚这些更改，我必须抛出一个新的RuntimeException？这并不是一个真正的RuntimeException（未经检查的异常），因为我已经在逻辑中确定了它。或者我误解了这些概念？

我真正的问题，在我的@Transactional服务方法中回滚事务的最佳实践是什么？如果您使用的是检查过的异常，只需将它们添加到 rollbackFor 中。 @Transactional 注解的属性。

= {MyInvalidUserException.class，MyApplicationException.class}）
public void method（）throws MyInvalidUserException，MyApplicationException {
...
...
}

etc。

org.life.java's em>答案也可以正常工作。如果您想要将编程式交易管理混合到您的声明式交易中或严格保持声明式交易，这是一项学术性决定。

Referencing Spring documentation:

Any RuntimeException will trigger rollback, and any checked Exception will not

Referencing javapractices.com

Unchecked exceptions :

• represent defects in the program (bugs) - often invalid arguments passed to a non-private method. To quote from The Java Programming Language, by Gosling, Arnold, and Holmes : "Unchecked runtime exceptions represent conditions that, generally speaking, reflect errors in your program's logic and cannot be reasonably recovered from at run time."
• are subclasses of RuntimeException, and are usually implemented using IllegalArgumentException, NullPointerException, or IllegalStateException
• a method is not obliged to establish a policy for the unchecked exceptions thrown by its implementation (and they almost always do not do so)

Checked exceptions :

• represent invalid conditions in areas outside the immediate control of the program (invalid user input, database problems, network outages, absent files)
• are subclasses of Exception
• a method is obliged to establish a policy for all checked exceptions thrown by its implementation (either pass the checked exception further up the stack, or handle it somehow)

If during my business logic I discover a problem and I want to rollback the changes, I have to throw a new RuntimeException? It's not really a RuntimeException (unchecked exception) since I've identified it in the logic. Or perhaps I'm misunderstanding these concepts?

My real question, what's best practices for rolling back a transaction in my @Transactional service methods?

解决方案

If you're using checked exceptions you simply add them to the rollbackFor property of your @Transactional annotation.

@Transactional(rollbackFor = { MyInvalidUserException.class, MyApplicationException.class })
public void method() throws MyInvalidUserException,  MyApplicationException { 
    ... 
    ... 
}

etc.

org.life.java's answer also works fine. It's an academic decision if you want to intermix programmatic transaction management into your declarative transactions or keep it strictly declarative.

这篇关于在Spring 3 / Hibernate中回滚事务的最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！