- 浏览: 580333 次
- 性别:
- 来自: 济南
文章分类
最新评论
-
18813188509:
请教,怎么在标题或者表头的前面显示导出报表的时间、数据数量…… ...
JeeSite的Excel导入、导出、支持大数据量,使用annotation最小化配置 -
u010199866:
2018-06-07 15:42:44 [com.cj ...
实现MyBatis Mapper XML文件增量动态刷新,自动加载,热加载,热部署 -
ccav1024:
大神好,下了您的代码,项目启动访问后,系统设置--机构用户-- ...
JeeSite 4.0 规划(二) -
juxiaojun114:
jeesite 使用idea导入开发,启动tomcat后为啥看 ...
实现MyBatis Mapper XML文件增量动态刷新,自动加载,热加载,热部署 -
aaddsfdsfsdfs:
真心给个赞,可以的,忒提高开发效率了,配合自己写的通用后台框架 ...
实现MyBatis Mapper XML文件增量动态刷新,自动加载,热加载,热部署
<script type="text/javascript">document.domain = "iteye.com";</script>
Mark Richards , 主管和高级技术架构师, Collaborative Consulting, LLC
2009 年 3 月 06 日
事务处理的目标应该是实现数据的高度完整性和一致性。本文是为 Java 平台开发有效事务策略 系列文章 的第一篇,介绍了一些妨碍您实现此目标的常见事务陷阱。本系列作者 Mark Richards 通过使用 Spring Framework 和企业 JavaBeans(Enterprise JavaBeans,EJB)3.0 规范中的代码示例解释了这些极其常见的错误。
<!-- START RESERVED FOR FUTURE USE INCLUDE FILES--><!-- include java script once we verify teams wants to use this and it will work on dbcs and cyrillic characters --> <!-- END RESERVED FOR FUTURE USE INCLUDE FILES-->
在应用程序中使用事务常常是为了维护高度的数据完整性和一致性。如果不关心数据的质量,就不必使用事务。毕竟,Java 平台中的事务支持会降低性能,引发锁定问题和数据库并发性问题,而且会增加应用程序的复杂性。
|
但是不关心事务的开发人员就会遇到麻烦。几乎所有与业务相关的应用程序都需要高度的数据质量。金融投资行业在失败的交易上浪费数百亿美元,不好的数据是导致这种结果的第二大因素(请参阅 参考资料 )。尽然缺少事务支持只是导致坏数据的一个因素(但是是主要的因素),但是完全可以这样认为,在金融投资行业浪费掉数十亿美元是由于缺少事务支持或事务支持不充分。
忽略事务支持是导致问题的另一个原因。我常常听到 “我们的应用程序中不需要事务支持,因为这些应用程序从来不会失败” 之类的说法。是的,我知道有些应用程序极少或从来不会抛出异常。这些应用程序基于编写良好的代码、编写良好的验证例程,并经过了充分的测试,有代码覆盖支持,可以避免性能损耗和与事务处理有关的复杂性。这种类型的应用程序只需考虑事务支持的一个特性:原子性 。原子性确保所有更新被当作一个单独的单元,要么全部提交,要么回滚。但是回滚或同时更新不是事务支持的惟一方面。另一方面,隔离性 将确保某一工作单元独立于其他工作单元。没有适当的事务隔离性,其他工作单元就可以访问某一活动工作单元所做的更新,即使该工作单元还未完成。这样,就会基于部分数据作出业务决策,而这会导致失败的交易或产生其他负面(或代价昂贵的)结果。
|
因此,考虑到坏数据的高成本和负面影响,以及事务的重要性(和必须性)这些基本常识,您需要使用事务处理并学习如何处理可能出现的问题。您在应用程序中添加事务支持后常常会出现很多问题。事务在 Java 平台中并不总是如预想的那样工作。本文会探讨其中的原因。我将借助代码示例,介绍一些我在该领域中不断看到的和经历的常见事务陷阱,大部分是在生产环境中。
虽然本文中的大多数代码示例使用的是 Spring Framework(version 2.5),但事务概念与 EJB 3.0
规范中的是相同的。在大多数情况下,用 EJB 3.0 规范中的 _cnnew1@TransactionAttribute
注释替换
Spring Framework @Transactional
注释即可。如果这两种框架使用了不同的概念和技术,我将同时给出
Spring Framework 和 EJB 3.0 源代码示例。
最好先从最简单的场景开始,即使用本地事务
,一般也称为数据库事务
。在数据库持久性的早期(例如
JDBC),我们一般会将事务处理委派给数据库。毕竟这是数据库应该做的。本地事务很适合执行单一插入、更新或删除语句的逻辑工作单元(LUW)。例如,考虑清单 1
中的简单 JDBC 代码,它向 TRADE
表插入一份股票交易订单:
@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 所示:
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
表内,这会导致数据库出现不一致的数据。如果 placeTrade()
方法使用了事务,这两个活动都会包含在一个 LUW
中,如果帐户更新失败,交易订单就会回滚。
随着 Java 持久性框架的不断普及,如 Hibernate、TopLink 和 Java 持久性 API(Java Persistence
API,JPA),我们很少再会去编写简单的 JDBC
代码。更常见的情况是,我们使用更新的对象关系映射(ORM)框架来减轻工作,即用几个简单的方法调用替换所有麻烦的 JDBC 代码。例如,要插入 清单
1
中 JDBC 代码示例的交易订单,使用带有 JPA 的 Spring Framework,就可以将 TradeData
对象映射到 TRADE
表,并用清单 3 中的 JPA 代码替换所有 JDBC 代码:
public class TradingServiceImpl { @PersistenceContext(unitName="trading") EntityManager em; public long insertTrade(TradeData trade) throws Exception { em.persist(trade); return trade.getTradeId(); } } |
注意,清单 3 在 EntityManager
上调用了 persist()
方法来插入交易订单。很简单,是吧?其实不然。这段代码不会像预期那样向 TRADE
表插入交易订单,也不会抛出异常。它只是返回一个值
0
作为交易订单的键,而不会更改数据库。这是事务处理的主要陷阱之一:基于 ORM
的框架需要一个事务来触发对象缓存与数据库之间的同步
。这通过一个事务提交完成,其中会生成 SQL
代码,数据库会执行需要的操作(即插入、更新、删除)。没有事务,就不会触发 ORM 去生成 SQL 代码和保存更改,因此只会终止方法 —
没有异常,没有更新。如果使用基于 ORM 的框架,就必须利用事务。您不再依赖数据库来管理连接和提交工作。
这些简单的示例应该清楚地说明,为了维护数据完整性和一致性,必须使用事务。不过对于在 Java 平台中实现事务的复杂性和陷阱而言,这些示例只是涉及了冰山一角。
|
|
Spring Framework
@Transactional
注释陷阱
您将测试 清单
3
中的代码,发现 persist()
方法在没有事务的情况下不能工作。因此,您通过简单的网络搜索查看几个链接,发现如果使用
Spring Framework,就需要使用 @Transactional
注释。于是您在代码中添加该注释,如清单 4 所示:
public class TradingServiceImpl { @PersistenceContext(unitName="trading") EntityManager em; @Transactional public long insertTrade(TradeData trade) throws Exception { em.persist(trade); return trade.getTradeId(); } } |
现在重新测试代码,您发现上述方法仍然不能工作。问题在于您必须告诉 Spring Framework,您正在对事务管理应用注释。除非您进行充分的单元测试,否则有时候很难发现这个陷阱。这通常只会导致开发人员在 Spring 配置文件中简单地添加事务逻辑,而不会使用注释。
要在 Spring 中使用 @Transactional
注释,必须在 Spring 配置文件中添加以下代码行:
<tx:annotation-driven transaction-manager="transactionManager"/> |
transaction-manager
属性保存一个对在 Spring 配置文件中定义的事务管理器 bean
的引用。这段代码告诉 Spring 在应用事务拦截器时使用 @Transaction
注释。如果没有它,就会忽略
@Transactional
注释,导致代码不会使用任何事务。
让基本的 @Transactional
注释在 清单
4
的代码中工作仅仅是开始。注意,清单 4 使用 @Transactional
注释时没有指定任何额外的注释参数。我发现许多开发人员在使用 @Transactional
注释时并没有花时间理解它的作用。例如,像我一样在清单 4 中单独使用 @Transactional
注释时,事务传播模式被设置成什么呢?只读标志被设置成什么呢?事务隔离级别的设置是怎样的?更重要的是,事务应何时回滚工作?理解如何使用这个注释对于确保在应用程序中获得合适的事务支持级别非常重要。回答我刚才提出的问题:在单独使用不带任何参数的
@Transactional
注释时,传播模式要设置为 REQUIRED
,只读标志设置为
false
,事务隔离级别设置为 READ_COMMITTED
,而且事务不会针对受控异常(checked
exception)回滚。
|
|
我在工作中经常碰到的一个常见陷阱是 Spring @Transactional
注释中的只读标志没有得到恰当使用。这里有一个快速测试方法:在使用标准 JDBC 代码获得 Java 持久性时,如果只读标志设置为
true
,传播模式设置为 SUPPORTS
,清单 5 中的
@Transactional
注释的作用是什么呢?
清单 5. 将只读标志与
SUPPORTS
传播模式结合使用 — JDBC
@Transactional(readOnly = true, propagation=Propagation.SUPPORTS) public long insertTrade(TradeData trade) throws Exception { //JDBC Code... } |
当执行清单 5 中的 insertTrade()
方法时,猜一猜会得到下面哪一种结果:
- 抛出一个只读连接异常
- 正确插入交易订单并提交数据
- 什么也不做,因为传播级别被设置为
SUPPORTS
是哪一个呢?正确答案是 B。交易订单会被正确地插入到数据库中,即使只读标志被设置为 true
,且事务传播模式被设置为
SUPPORTS
。但这是如何做到的呢?由于传播模式被设置为 SUPPORTS
,所以不会启动任何事物,因此该方法有效地利用了一个本地(数据库)事务。只读标志只在事务启动时应用。在本例中,因为没有启动任何事务,所以只读标志被忽略。
如果是这样的话,清单 6 中的 @Transactional
注释在设置了只读标志且传播模式被设置为
REQUIRED
时,它的作用是什么呢?
清单 6. 将只读标志与
REQUIRED
传播模式结合使用 — JDBC
@Transactional(readOnly = true, propagation=Propagation.REQUIRED) public long insertTrade(TradeData trade) throws Exception { //JDBC code... } |
执行清单 6 中的 insertTrade()
方法会得到下面哪一种结果呢:
- 抛出一个只读连接异常
- 正确插入交易订单并提交数据
- 什么也不做,因为只读标志被设置为
true
根据前面的解释,这个问题应该很好回答。正确的答案是
A。会抛出一个异常,表示您正在试图对一个只读连接执行更新。因为启动了一个事务(REQUIRED
),所以连接被设置为只读。毫无疑问,在试图执行 SQL 语句时,您会得到一个异常,告诉您该连接是一个只读连接。
关于只读标志很奇怪的一点是:要使用它,必须启动一个事务。如果只是读取数据,需要事务吗?答案是根本不需要。启动一个事务来执行只读操作会增加处理线程的开销,并会导致数据库发生共享读取锁定(具体取决于使用的数据库类型和设置的隔离级别)。总的来说,在获取基于 JDBC 的 Java 持久性时,使用只读标志有点毫无意义,并会启动不必要的事务而增加额外的开销。
使用基于 ORM 的框架会怎样呢?按照上面的测试,如果在结合使用 JPA 和 Hibernate 时调用
insertTrade()
方法,清单 7 中的 @Transactional
注释会得到什么结果?
清单 7. 将只读标志与
REQUIRED
传播模式结合使用 — JPA
@Transactional(readOnly = true, propagation=Propagation.REQUIRED) public long insertTrade(TradeData trade) throws Exception { em.persist(trade); return trade.getTradeId(); } |
清单 7 中的 insertTrade()
方法会得到下面哪一种结果:
- 抛出一个只读连接异常
- 正确插入交易订单并提交数据
- 什么也不做,因为
readOnly
标志被设置为 true
正确的答案是 B。交易订单会被准确无误地插入数据库中。请注意,上一示例表明,在使用 REQUIRED
传播模式时,会抛出一个只读连接异常。使用 JDBC 时是这样。使用基于 ORM 的框架时,只读标志只是对数据库的一个提示,并且一条基于 ORM
框架的指令(本例中是 Hibernate)将对象缓存的 flush 模式设置为 NEVER
,表示在这个工作单元中,该对象缓存不应与数据库同步。不过,REQUIRED
传播模式会覆盖所有这些内容,允许事务启动并工作,就好像没有设置只读标志一样。
这令我想到了另一个我经常碰到的主要陷阱。阅读了前面的所有内容后,您认为如果只对 @Transactional
注释设置只读标志,清单 8 中的代码会得到什么结果呢?
@Transactional(readOnly = true) public TradeData getTrade(long tradeId) throws Exception { return em.find(TradeData.class, tradeId); } |
清单 8 中的 getTrade()
方法会执行以下哪一种操作?
- 启动一个事务,获取交易订单,然后提交事务
- 获取交易订单,但不启动事务
正确的答案是 A。一个事务会被启动并提交。不要忘了,@Transactional
注释的默认传播模式是
REQUIRED
。这意味着事务会在不必要的情况下启动。根据使用的数据库,这会引起不必要的共享锁,可能会使数据库中出现死锁的情况。此外,启动和停止事务将消耗不必要的处理时间和资源。总的来说,在使用基于
ORM 的框架时,只读标志基本上毫无用处,在大多数情况下会被忽略。但如果您坚持使用它,请记得将传播模式设置为 SUPPORTS
(如清单 9 所示),这样就不会启动事务:
清单 9. 使用只读标志和
SUPPORTS
传播模式进行选择操作
@Transactional(readOnly = true, propagation=Propagation.SUPPORTS) public TradeData getTrade(long tradeId) throws Exception { return em.find(TradeData.class, tradeId); } |
另外,在执行读取操作时,避免使用 @Transactional
注释,如清单 10 所示:
清单 10. 删除
@Transactional
注释进行选择操作
public TradeData getTrade(long tradeId) throws Exception { return em.find(TradeData.class, tradeId); } |
|
|
不管是使用 Spring Framework,还是使用 EJB,使用 REQUIRES_NEW
事务属性都会得到不好的结果并导致数据损坏和不一致。REQUIRES_NEW
事务属性总是会在启动方法时启动一个新的事务。许多开发人员都错误地使用 REQUIRES_NEW
属性,认为它是确保事务启动的正确方法。考虑清单 11 中的两个方法:
@Transactional(propagation=Propagation.REQUIRES_NEW) public long insertTrade(TradeData trade) throws Exception {...} @Transactional(propagation=Propagation.REQUIRES_NEW) public void updateAcct(TradeData trade) throws Exception {...} |
注意,清单 11 中的两个方法都是公共方法,这意味着它们可以单独调用。当使用 REQUIRES_NEW
属性的几个方法通过服务间通信或编排在同一逻辑工作单元内调用时,该属性就会出现问题。例如,假设在清单 11 中,您可以独立于一些用例中的任何其他方法来调用
updateAcct()
方法,但也有在 insertTrade()
方法中调用
updateAcct()
方法的情况。现在如果调用 updateAcct()
方法后抛出异常,交易订单就会回滚,但帐户更新将会提交给数据库,如清单 12 所示:
清单 12. 使用
REQUIRES_NEW
事务属性的多次更新
@Transactional(propagation=Propagation.REQUIRES_NEW) public long insertTrade(TradeData trade) throws Exception { em.persist(trade); updateAcct(trade); //exception occurs here! Trade rolled back but account update is not! ... } |
之所以会发生这种情况是因为 updateAcct()
方法中启动了一个新事务,所以在
updateAcct()
方法结束后,事务将被提交。使用 REQUIRES_NEW
事务属性时,如果存在现有事务上下文,当前的事务会被挂起并启动一个新事务。方法结束后,新的事务被提交,原来的事务继续执行。
由于这种行为,只有在被调用方法中的数据库操作需要保存到数据库中,而不管覆盖事务的结果如何时,才应该使用 REQUIRES_NEW
事务属性。比如,假设尝试的所有股票交易都必须被记录在一个审计数据库中。出于验证错误、资金不足或其他原因,不管交易是否失败,这条信息都需要被持久化。如果没有对审计方法使用
REQUIRES_NEW
属性,审计记录就会连同尝试执行的交易一起回滚。使用 REQUIRES_NEW
属性可以确保不管初始事务的结果如何,审计数据都会被保存。这里要注意的一点是,要始终使用 MANDATORY
或
REQUIRED
属性,而不是 REQUIRES_NEW
,除非您有足够的理由来使用它,类似审计示例中的那些理由。
|
|
我将最常见的事务陷阱留到最后来讲。遗憾的是,我在生产代码中多次???到这个错误。我首先从 Spring Framework 开始,然后介绍 EJB 3。
到目前为止,您研究的代码类似清单 13 所示:
@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 受控异常,表示邮件无法发送。如果受控异常引起自动回滚,整个图书订单就会由于电子邮件服务器的关闭全部回滚。通过禁止自动回滚受控异常,您可以捕获该异常并执行某种纠正操作(如向挂起队列发送消息),然后提交剩余的订单。
使用 Declarative 事务模式(本系列的第 2 部分将进行更加详细的描述)时,必须指定容器或框架应该如何处理受控异常。在 Spring
Framework 中,通过 @Transactional
注释中的 rollbackFor
参数进行指定,如清单 14 所示:
@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 所示:
@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
事务属性。
|
|
用于在 Java 平台中实现事务的代码不是太复杂;但是,如何使用以及如何配置它就有一些复杂了。在 Java 平台中实现事务支持有许多陷阱(包括一些我未在本文中讨论的、不是很常见的陷阱)。大多数陷阱最大的问题是,不会有任何编译器警告或运行时错误告诉您事务实现是不正确的。而且,与本文开头的 “迟做总比不做好 ” 部分的内容相反,实现事务支持不仅仅是一个编码工作。开发一个完整的事务策略涉及大量的设计工作。事务策略 系列的其余部分将指导您如何设计针对从简单应用程序到高性能事务处理用例的有效事务策略。
学习
- 您可以参阅本文在 developerWorks 全球网站上的 英文原文
。
-
Straight
Through Processing for Financial Service Firms
(Hal McIntyre,Summit
Group 出版社,2004):了解在金融服务事务处理中,更多有关造成坏数据的原因及其成本的信息。
-
Java
Transaction Design Strategies
(Mark Richards,C4Media 出版,2006):本书深入讨论了
Java 平台中的事务。
-
Java
Transaction Processing
(Mark Little,Prentice
Hall,2004):本书是另一本比较好的关于事务的参考书。
-
第
9 章. 事务管理
:在 Spring Framework 2.5 文档的这部分中,可以找到更多有关 Spring 事务处理的信息。
-
Enterprise JavaBeans 3.0
资源站点:在此可以找到有关 EJB 3.0 规范的文档。
- 浏览 技术书店
,查阅有关本文所述主题及其他技术主题的图书。
-
developerWorks Java
技术专区
:提供了几百篇有关 Java 编程的各个方面的文章。
讨论
- 参与 developerWorks blogs 并加入 developerWorks 社区 。
Mark Richards 是 Collaborative Consulting, LLC 的主管和高级技术架构师。他是第 2 版 Java Message Service (O'Reilly,2009)和 Java Transaction Design Strategies (C4Media Publishing,2006)的作者。他也是其他几本书的丛集著者,包括 97 Things Every Software Architect Should Know (O'Reilly,2009)、NFJS Anthology Volume 1 (Pragmatic Bookshelf,2006)和 NFJS Anthology Volume 2 (Pragmatic Bookshelf,2007)。Mark 拥有 IBM、Sun、The Open Group 和 BEA 的架构师和开发人员证书。他是 No Fluff Just Stuff 专题讨论会的定期演讲者,并在世界各地的其他会议和用户组中进行演讲。 |
发表评论
-
JeeSite 4.0 简化MyBatis持久层开发
2017-08-06 19:22 1545引言 更好的阅读体验点这里:https:/ ... -
JeeSite 4.0 规划(二)
2017-06-03 16:03 10787==== 点击放大查看 ==== ==== 点击放大查 ... -
实现MyBatis Mapper XML文件增量动态刷新,自动加载,热加载,热部署
2016-06-13 10:40 34815最初启动服务后Mapper XML文件,必须重启服 ... -
Java如何正确地写出单例模式
2015-12-02 11:25 3974单例模式算是设计模式中最容易理解,也是最容易手写代码的模式了 ... -
Spring事务管理(注解式声明事务管理)备忘
2015-06-06 09:11 6635步骤一、在spring配置文件中引入<tx:>命名 ... -
spring中,在Java任何位置获取request对象
2014-11-01 14:04 11745看RequestContextListener和Re ... -
POI实现超大数据的Excel的读写操作,支持Excel最大行数。
2014-11-01 13:34 28723前端时间写了注解方 ... -
Java 6 JVM参数选项大全(中文版)
2013-12-09 09:57 2601作者:Ken Wu Email: ken.wug@gma ... -
JeeSite 企业信息管理系统基础框架 V1.0.3 发布
2013-06-03 14:35 83784框架简介: JeeSite是一个 开源的企业信息管 ... -
JeeSite 目录结构介绍
2013-02-27 18:15 7278项目地址:http://thinkgem.github. ... -
JeeSite 企业信息管理系统基础框架(开源项目)
2013-02-19 21:55 19610框架简介 JeeSite是一 ... -
WebEffect网页特效集锦系统(开源)
2013-01-19 02:05 2914介绍 网页特效是用程序代码在网页中实现特殊效果或者特殊功 ... -
Java工厂模式
2011-08-19 11:27 1338看着这篇文章些的不错 ... -
List排序类
2010-11-30 11:33 1635import java.lang.reflect.Invoca ... -
批量生成 Hibernate Dao
2010-08-02 12:06 1160/** * 批量生成 Hibernate Dao * ... -
Hibernate 配置
2010-08-02 11:55 947由于Hibernate是为了能在 ... -
spring+hibernate+jbpm3整合
2010-08-02 11:55 1211<?xml version="1.0" ... -
Java冒泡排序算法
2010-08-02 11:52 1132/** * 冒泡排序算法 * @author W ... -
在Struts2中方便获得Spring中的Bean方法
2010-08-02 11:49 1541FormService formService = (F ... -
Hibernate 关键字Key的自动生成
2010-08-02 11:48 1532Id Generator 标识符生成器 描述 incre ...
相关推荐
分布式事务应用:支付宝分布式事务设计 分布式事务应用:支付宝分布式事务设计
论文研究-会计师事务所风险管理策略: 高阶期望风险视角.pdf, 根据会计师事务所客户组合的风险特征,在给出客户组合风险的高阶期望损失风险测度方法的基础上,建立了客户...
JTA(Java Transaction API) 为 J2EE 平台提供了分布式事务服务。 要用 JTA 进行事务界定,应用程序要调用 javax.transaction.UserTransaction 接口中的方法。
事务处理:概念与技术,数据库界唯一一位获得图灵奖的大师的亲笔所作
我希望这个专栏能够帮助这样的一些开发者:他们正在...他们听说了一些使用数据库 的最佳实践,但是更想了解为什么这么做;他们使用的数据库偶尔会出问题,亟需了解如何更快 速、更准确地定位问题,甚至自己解决问题……
UNStudio建筑事务所:技术与逻辑.pdf
大家跨服务器加事务的时候经常遇到以下报错:导入Microsoft分布式事务处理协调器MSDTC,网上大部分教程都是服务器配置msdtc,但是发现两个服务器都配置之后还是不行,可参照此图片解决,已验证过,不好用找我,最低...
gmp建筑事务所:中国国家博物馆归类.pdf
03丨事务隔离:为什么你改了我还看不见?.html
java事务设计策略
03事务隔离:为什么你改了我还看不见?.pptx
国浩律师事务所:2022中国氢能产业专利观察报告(115页).pdf
Java事务设计策略 Mark Richards 编著 翟静 翻译 InfoQ软件开发丛书
北京来硕律师事务所:阳江市市区国有土地上房屋征收与补偿办法.pdf
事务隔离 查询:默认事务隔离级别 mysql> select @@tx_isolation;当前会话的默认事务隔离级别 mysql> select @@session.tx_isolation;当前会话的默认事务隔离级别 mysql> select @@global.tx_isolation;全局的事务...
深入理解分布式事务
此外,Spring事务管理器支持多种类型的事务策略,包括不同的传播行为和隔离级别,允许开发者根据具体业务场景选择最合适的事务管理策略。深入理解Spring声明式事务的工作原理,不仅能帮助开发者更高效地使用Spring...