Spring 注解@Transactional

你是否正在寻找关于transactional的内容？让我把最内涵的东西奉献给你：

Spring事务的传播行为
在service类前加上@transactional，声明这个service所有方法需要事务管理。每一个业务方法开始时都会打开一个事务。
Spring默认情况下会对运行期例内被调用，则方法成为该事务的一部分。如果方法在该事务范围内执行。如果在就抛例外。只有该方法没有关联到任何事务，才正常执行。
NESTED:如果一个活动的事务存在，则运行在一个嵌套的事务中。如果没有活动事务，则按REQUIRED属性执行。它使用了一个单独的事务，这个事务拥有多个可以回滚的保存点。内部事务的回滚不会对外部事务造成影响。它只对DataSourceTransactionManager事务管理器起效。
事务陷阱-1
清单 1. 使用 JDBC 的简单插入
view plaincopy to clipboardprint?
@Stateless
public class TradingServiceImpl implements TradingService {
@Resource SessionContext ctx;
@Resource(mappedName="java:jdbc/tradingDS") DataSource ds;
public long insertTrade(TradeData trade) throws Exception {
Connection dbConnection = ds.getConnection();
try {
Statement sql = dbConnection.createStatement();
String stmt =
"INSERT INTO TRADE (ACCT_ID, SIDE, SYMBOL, SHARES, PRICE, STATE)"
+ "VALUES ("
+ trade.getAcct() + "','"
+ trade.getAction() + "','"
+ trade.getSymbol() + "',"
+ trade.getShares() + ","
+ trade.getPrice() + ",'"
+ trade.getState() + "')";
sql.executeUpdate(stmt, Statement.RETURN_GENERATED_KEYS);
ResultSet rs = sql.getGeneratedKeys();
if (rs.next()) {
return rs.getBigDecimal(1).longValue();
} else {
throw new Exception("Trade Order Insert Failed");
}
} finally {
if (dbConnection != null) dbConnection.close();
}
}
}
@Stateless
public class TradingServiceImpl implements TradingService {
@Resource SessionContext ctx;
@Resource(mappedName="java:jdbc/tradingDS") DataSource ds;
public long insertTrade(TradeData trade) throws Exception {
Connection dbConnection = ds.getConnection();
try {
Statement sql = dbConnection.createStatement();
String stmt =
"INSERT INTO TRADE (ACCT_ID, SIDE, SYMBOL, SHARES, PRICE, STATE)"
+ "VALUES ("
+ trade.getAcct() + "','"
+ trade.getAction() + "','"
+ trade.getSymbol() + "',"
+ trade.getShares() + ","
+ trade.getPrice() + ",'"
+ trade.getState() + "')";
sql.executeUpdate(stmt, Statement.RETURN_GENERATED_KEYS);
ResultSet rs = sql.getGeneratedKeys();
if (rs.next()) {
return rs.getBigDecimal(1).longValue();
} else {
throw new Exception("Trade Order Insert Failed");
}
} finally {
if (dbConnection != null) dbConnection.close();
}
}
}
清单 1 中的 JDBC 代码没有包含任何事务逻辑，它只是在中保存 TRADE 表中的交易订单。在本例中，处理事务逻辑。
在 LUW 中，这是一个不错的单个维护操作。但是如果需要在向插入交易订单的同时更新帐户余款呢？如清单 2 所示：
清单 2. 在同一方法中执行多次表更新
view plaincopy to clipboardprint?
public TradeData placeTrade(TradeData trade) throws Exception {
try {
insertTrade(trade);
updateAcct(trade);
return trade;
} catch (Exception up) {
//log the error
throw up;
}
}
public TradeData placeTrade(TradeData trade) throws Exception {
try {
insertTrade(trade);
updateAcct(trade);
return trade;
} catch (Exception up) {
//log the error
throw up;
}
}
在本例中，insertTrade() 和 updateAcct() 方法使用不带事务的标准 JDBC 代码。insertTrade() 方法结束后，保存（并提交了）交易订单。如果 updateAcct() 方法由于任意原因失败，交易订单仍然会在 placeTrade() 方法结束时保存在 TRADE 表内，这会导致出不足或其他原因，不管交易是否失败，这条信息都需要被持久化。如果没有对审计方法使用 REQUIRES_NEW 属性，审计记录就会连同尝试执行的交易一起回滚。使用 REQUIRES_NEW 属性可以确保不管初始事务的结果如何，审计数据都会被保存。这里要注意的一点是，要始终使用 MANDATORY 或 REQUIRED 属性，而不是 REQUIRES_NEW，除非您有足够的理由来使用它，类似审计示例中的那些理由。
事务回滚陷阱
我将最常见的事务陷阱留到最后来讲。遗憾的是，我在生产代码中多次遇到这个错误。我首先从 Spring Framework 开始，然后介绍 EJB 3。
到目前为止，您研究的代码类似清单 13 所示：
清单 13. 没有回滚支持
view plaincopy to clipboardprint?
@transactional(propagation=Propagation.REQUIRED)
public TradeData placeTrade(TradeData trade) throws Exception {
try {
insertTrade(trade);
updateAcct(trade);
return trade;
} catch (Exception up) {
//log the error
throw up;
}
}
@transactional(propagation=Propagation.REQUIRED)
public TradeData placeTrade(TradeData trade) throws Exception {
try {
insertTrade(trade);
updateAcct(trade);
return trade;
} catch (Exception up) {
//log the error
throw up;
}
}
假设帐户中没有足够的资金来购买需要的股票，或者还没有准备购买或出售股票，并抛出了一个受控异常（例如 FundsNotAvailableException），那么交易订单会保存在中吗？还是整个逻辑工作单元将执行回滚？答案出乎意料：根据受控异常（不管是在 Spring Framework 中还是在 EJB 中），事务会提交它还未提交的所有工作。使用清单 13，这意味着，如果在执行 updateAcct() 方法期间抛出受控异常，就会保存交易订单，但不会更新帐户来反映交易情况。
这可能是在使用事务时出现的主要数据完整性和一致性问题了。运行时异常（即非受控异常）自动强制执行整个逻辑工作单元的回滚，但受控异常不会。因此，清单 13 中的代码从事务角度来说毫无用处；尽管看上去它使用事务来维护原子性和一致性，但事实上并没有。
尽管这种行为看起来很奇怪，但这样做自有它的道理。首先，不是所有受控异常都是不好的；它们可用于事件通知或根据某些条件重定向处理。但更重要的是，应用程序代码会对某些类型的受控异常采取纠正操作，从而使事务全部完成。例如，考虑下面一种场景：您正在为书籍零售商编写代码。要完成图书的订单，您需要将电子邮件形式的确认函作为订单处理的一部分发送。如果电子邮件服务器关闭，您将发送某种形式的 SMTP 受控异常，表示邮件无法发送。如果受控异常引起自动回滚，整个图书订单就会由于电子邮件服务器的关闭全部回滚。通过禁止自动回滚受控异常，您可以捕获该异常并执行某种纠正操作（如向挂起队列发送消息），然后提交剩余的订单。
Spring Framework @transactional 注释陷阱-6
使用 Declarative 事务模式时，必须指定容器或框架应该如何处理受控异常。在 Spring Framework 中，通过 @transactional 注释中的 rollbackFor 参数进行指定，如清单 14 所示：
清单 14. 添加事务回滚支持 — Spring
view plaincopy to clipboardprint?
@transactional(propagation=Propagation.REQUIRED, rollbackFor=Exception.class)
public TradeData placeTrade(TradeData trade) throws Exception {
try {
insertTrade(trade);
updateAcct(trade);
return trade;
} catch (Exception up) {
//log the error
throw up;
}
}
@transactional(propagation=Propagation.REQUIRED, rollbackFor=Exception.class)
public TradeData placeTrade(TradeData trade) throws Exception {
try {
insertTrade(trade);
updateAcct(trade);
return trade;
} catch (Exception up) {
//log the error
throw up;
}
}
注意，@transactional 注释中使用了 rollbackFor 参数。这个参数接受一个单一异常类或一组异常类，您也可以使用 rollbackForClassName 参数将异常的名称指定为 Java String 类型。还可以使用此属性的相反形式（noRollbackFor）指定除某些异常以外的所有异常应该强制回滚。通常大多数开发人员指定 Exception.class 作为值，表示该方法中的所有异常应该强制回滚。
在回滚事务这一点上，EJB 的工作方式与 Spring Framework 稍微有点不同。EJB 3.0 规范中的 @TransactionAttribute 注释不包含指定回滚行为的指令。必须使用 SessionContext.setRollbackOnly() 方法将事务标记为执行回滚，如清单 15 所示：
清单 15. 添加事务回滚支持 — EJB
view plaincopy to clipboardprint?
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public TradeData placeTrade(TradeData trade) throws Exception {
try {
insertTrade(trade);
updateAcct(trade);
return trade;
} catch (Exception up) {
//log the error
sessionCtx.setRollbackOnly();
throw up;
}
}
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public TradeData placeTrade(TradeData trade) throws Exception {
try {
insertTrade(trade);
updateAcct(trade);
return trade;
} catch (Exception up) {
//log the error
sessionCtx.setRollbackOnly();
throw up;
}
}
调用 setRollbackOnly() 方法后，就不能改变主意了；惟一可能的结果是在启动事务的方法完成后回滚事务。本系列后续文章中描述的事务策略将介绍何时、何处使用回滚指令，以及何时使用 REQUIRED 与 MANDATORY 事务属性。
Isolation Level(事务隔离等级)
1、Serializable：最严格的级别，事务串行执行，资源消耗最大；
2、REPEATABLE READ：保证了一个事务不会修改已经由另一个事务读取但未提交（回滚）的数据。避免了“脏读取”和“不可重复读取”的情况，但是带来了更多的性能损失。
3、READ COMMITTED:大多数主流的默认事务等级，保证了一个事务不会读到另一个并行事务已修改但未提交的数据，避免了“脏读取”。该级别适用于大多数系统。
4、Read Uncommitted：保证了读取过程中不会读取到非法数据。隔离级别在于处理多事务的并发问题。
我们知道并行可以提高的吞吐量和效率，但是并不是所有的并发事务都可以并发运行。
我们首先说并发中可能发生的3中不讨人喜欢的事情
1： Dirty reads--读脏数据。也就是说，比如事务A的未提交（还依然缓存）的数据被事务B读走，如果事务A失败回滚，会导致事务B所读取的的数据是错误的。
2： non-repeatable reads--数据不可重复读。比如事务A中两处读取数据-total-的值。在第一读的时候，total是100，然后事务B就把total的数据改成 200，事务A再读一次，结果就发现，total竟然就变成200了，造成事务A数据混乱。
3： phantom reads--幻象读数据，这个和non-repeatable reads相似，也是同一个事务中多次读不一致的问题。但是non-repeatable reads的不一致是因为他所要取的数据集被改变了（比如total的数据），但是phantom reads所要读的数据的不一致却不是他所要读的数据集改变，而是他的条件数据集改变。比如Select account.id where account.name="ppgogo*",第一次读去了6个符合条件的id，第二次读取的时候，由于事务b把一个帐号的名字由"dd"改成"ppgogo1"，结果取出来了7个数据。
Dirty reads non-repeatable reads phantom reads
Serializable 不会 不会 不会
REPEATABLE READ 不会 不会 会
READ COMMITTED 不会 会 会
Read Uncommitted 会 会 会
readOnly
事务属性中的readOnly标志表示对应的事务应该被最优化为只读事务。

以上就是关于transactional的全部内容，相信你一定会非常满意。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/shenmilingyu/article-4414-1.html