WEB开发网      濠电姷鏁告慨鐑藉极閸涘﹦绠鹃柍褜鍓氱换娑欐媴閸愬弶鎼愮痪鍓ф嚀閳规垿鎮╃€圭姴顥濋梺姹囧€楅崑鎾诲Φ閸曨垰绠涢柛顐f礃椤庡秹姊虹粙娆惧剳闁哥姵鍔欐俊鐢稿礋椤栨艾鍞ㄩ梺闈浤涙担鎻掍壕闁圭儤顨嗛埛鎺楁煕閺囥劌浜滄い蹇e弮閺屸€崇暆鐎n剛鏆犻柧浼欑到閵嗘帒顫濋悡搴d画缂佹鍨垮缁樻媴缁涘娈┑顔斤公缁犳捇銆佸鎰佹▌濠电姭鍋撳ù锝囩《閺€浠嬫煟濡鍤嬬€规悶鍎辫灃闁绘ê寮堕崯鐐电磼閸屾氨效鐎规洘绮忛ˇ瀵哥棯閹佸仮鐎殿喖鐖煎畷鐓庘槈濡警鐎崇紓鍌欑劍椤ㄥ棗鐣濋幖浣歌摕闁绘棃顥撻弳瀣煟濡も偓閻楀棗鈻撳Δ鍛拺閻犲洠鈧櫕鐏€闂佸搫鎳愭慨鎾偩閻ゎ垬浜归柟鐑樼箖閺呮繈姊洪棃娑氬婵☆偅鐟╅、娆掔疀閺冨倻鐦堥梺姹囧灲濞佳勭閿曞倹鐓曢柕濞垮劤閸╋絾顨ラ悙鏉戝妤犵偞锕㈤、娆撴嚃閳哄骞㈤梻鍌欐祰椤鐣峰Ο鑲╃煋妞ゆ棁锟ユ禍褰掓煙閻戞ɑ灏ù婊冪秺濮婅櫣绱掑Ο铏逛桓闂佹寧娲嶉弲娑滅亱闂佸憡娲﹂崹閬嶅煕閹达附鐓欓柤娴嬫櫅娴犳粌鈹戦垾鐐藉仮闁诡喗顨呴埥澶愬箳閹惧褰囩紓鍌欑贰閸犳牠顢栭崨鎼晣闁稿繒鍘х欢鐐翠繆椤栨粎甯涙繛鍛喘濮婄粯鎷呴悷閭﹀殝缂備浇顕ч崐鍨嚕缂佹ḿ绡€闁搞儯鍔嶅▍鍥⒑缁嬫寧婀扮紒瀣崌瀹曘垽鎮介崨濠勫幗闁瑰吋鐣崹濠氬煀閺囥垺鐓ユ慨妯垮煐閻撶喖鐓崶銉ュ姢缂佸宕电槐鎺旂磼濡偐鐣虹紓浣虹帛缁诲牆鐣峰鈧俊姝岊槺缂佽鲸绻堝缁樻媴缁涘娈愰梺鎼炲妺閸楀啿鐣烽鐐茬骇闁瑰濮靛▓楣冩⒑缂佹ɑ鈷掗柍宄扮墦瀵偊宕掗悙瀵稿幈闂佹娊鏁崑鎾绘煛閸涱喚鎳呮俊鍙夊姇铻i悶娑掑墲閺傗偓闂備胶绮崝鏇炍熸繝鍥у惞闁绘柨鐨濋弨鑺ャ亜閺冨洦顥夐柛鏂诲€濋幗鍫曟倷閻戞ḿ鍘遍梺鍝勬储閸斿本鏅堕鐐寸厱婵炲棗绻掔粻濠氭煛鐏炵晫效鐎规洦鍋婂畷鐔碱敆閳ь剙鈻嶉敐鍥╃=濞达絾褰冩禍鐐節閵忥絾纭炬い鎴濇川缁粯銈i崘鈺冨幍闁诲孩绋掑玻璺ㄧ不濮椻偓閺屻劌鈽夊Ο澶癸絾銇勯妸锝呭姦闁诡喗鐟╅、鏃堝礋椤撴繄绀勯梻鍌欐祰椤曟牠宕伴弽顐ょ濠电姴鍊婚弳锕傛煙椤栫偛浜版俊鑼额嚙閳规垿鍩勯崘銊хシ濡炪値鍘鹃崗妯侯嚕鐠囨祴妲堥柕蹇曞閳哄懏鐓忓璺虹墕閸旀挳鏌涢弬娆炬Ш缂佽鲸鎸婚幏鍛矙鎼存挸浜鹃柛婵勫劤閻挾鎲搁悧鍫濈瑨闁哄绶氶弻鐔煎礈瑜忕敮娑㈡煛閸涱喗鍊愰柡灞诲姂閹倝宕掑☉姗嗕紦 ---闂傚倸鍊搁崐鎼佸磹閻戣姤鍊块柨鏃堟暜閸嬫挾绮☉妯哄箻婵炲樊浜滈悡娑㈡煕濞戝崬骞樻い鏂挎濮婅櫣鎹勯妸銉︾彚闂佺懓鍤栭幏锟�
开发学院软件开发Java Spring 事务管理高级应用难点剖析: 第 2 部分 阅读

Spring 事务管理高级应用难点剖析: 第 2 部分

 2010-03-29 00:00:00 来源:WEB开发网 闂傚倸鍊搁崐鎼佸磹妞嬪孩顐芥慨姗嗗厳缂傛氨鎲稿鍫罕闂備礁婀遍搹搴ㄥ窗閺嶎偆涓嶆い鏍仦閻撱儵鏌i弴鐐测偓鍦偓姘炬嫹闂傚倸鍊搁崐鎼佸磹妞嬪海鐭嗗〒姘e亾妤犵偛顦甸弫鎾绘偐閹绘帞鈧參姊哄Ч鍥х仼闁诲繑鑹鹃悾鐑藉蓟閵夛妇鍘甸梺瑙勵問閸犳牠銆傛總鍛婄厱閹艰揪绱曟牎闂侀潧娲ょ€氫即鐛幒妤€绠f繝闈涘暙娴滈箖鏌i姀鈶跺湱澹曟繝姘厵闁绘劦鍓氶悘杈ㄤ繆閹绘帞澧涚紒缁樼洴瀹曞崬螖閸愬啠鍓濈换娑樼暆婵犱胶鏁栫紓浣介哺閹瑰洤鐣烽幒鎴僵闁瑰吀鐒﹂悗鎼佹⒒娴g儤鍤€闁搞倖鐗犻獮蹇涙晸閿燂拷濠电姷鏁告慨鐑藉极閸涘﹥鍙忔い鎾卞灩缁狀垶鏌涢幇闈涙灈鐎瑰憡绻冮妵鍕箻鐎靛摜鐣奸梺纭咁潐濞茬喎顫忕紒妯肩懝闁逞屽墮宀h儻顦查悡銈夋煏閸繃鍋繛宸簻鎯熼梺瀹犳〃閼冲爼宕濋敃鈧—鍐Χ閸℃鐟愰梺鐓庡暱閻栧ジ宕烘繝鍥у嵆闁靛骏绱曢崢顏堟⒑閹肩偛鍔楅柡鍛⊕缁傛帟顦寸紒杈ㄥ笚濞煎繘鍩℃担閿嬵潟闂備浇妗ㄩ悞锕傚箲閸ヮ剙鏋侀柟鍓х帛閺呮悂鏌ㄩ悤鍌涘闂傚倸鍊搁崐鎼佸磹妞嬪孩顐芥慨姗嗗厳缂傛氨鎲稿鍫罕闂備礁婀遍搹搴ㄥ窗閺嶎偆涓嶆い鏍仦閻撱儵鏌i弴鐐测偓鍦偓姘炬嫹  闂傚倸鍊搁崐鎼佸磹閻戣姤鍤勯柤鍝ユ暩娴犳氨绱撻崒娆掑厡缂侇噮鍨堕妴鍐川閺夋垹鍘洪悗骞垮劚椤︻垶宕¢幎鑺ョ厪闊洦娲栨牎闂佽瀵掗崜鐔奉潖閾忓湱纾兼俊顖氭惈椤秴顪冮妶鍡楀闁告鍥х叀濠㈣泛谩閻斿吋鐓ラ悗锝庡厴閸嬫挻绻濆顓涙嫼閻熸粎澧楃敮鎺撶娴煎瓨鐓曢柟鎯ь嚟閳藉鏌嶇紒妯荤叆妞ゎ偅绻堥幊婊呭枈濡顏归梻鍌欑閹诧紕绮欓幋锔哄亼闁哄鍨熼弸鏃堟煛閸愶絽浜剧紓浣虹帛缁嬫挻绂掗敃鍌氱<婵﹩鍓﹂悗鎶芥⒒娴e摜锛嶇紒顕呭灦楠炴垿宕堕鍌氱ウ闁诲函缍嗘禍鏍绩娴犲鐓欓梺顓ㄧ畱婢ь垱銇勯弬鍨偓瑙勭┍婵犲洦鍊锋い蹇撳閸嬫捇寮借濞兼牕鈹戦悩瀹犲闁稿被鍔庨幉姝岀疀濞戞ḿ鐤呴梺鍦檸閸犳寮查幖浣圭叆闁绘洖鍊圭€氾拷
核心提示:联合军种作战的混乱Spring 抽象的 DAO 体系兼容多种数据访问技术,它们各有特色,Spring 事务管理高级应用难点剖析: 第 2 部分,各有千秋,像 Hibernate 是非常优秀的 ORM 实现方案,哪些情况会造成数据连接的泄漏,以及如何应对;除 Spring JDBC 外,但对底层 SQL 的控制不太方便;

联合军种作战的混乱

Spring 抽象的 DAO 体系兼容多种数据访问技术,它们各有特色,各有千秋。像 Hibernate 是非常优秀的 ORM 实现方案,但对底层 SQL 的控制不太方便;而 iBatis 则通过模板化技术让您方便地控制 SQL,但没有 Hibernate 那样高的开发效率;自由度最高的当然是直接使用 Spring JDBC 莫属了,但是它也是最底层的,灵活的代价是代码的繁复。很难说哪种数据访问技术是最优秀的,只有在某种特定的场景下,才能给出答案。所以在一个应用中,往往采用多个数据访问技术:一般是两种,一种采用 ORM 技术框架,而另一种采用偏 JDBC 的底层技术,两者珠联璧合,形成联合军种,共同御敌。

但是,这种联合军种如何应对事务管理的问题呢?我们知道 Spring 为每种数据访问技术提供了相应的事务管理器,难道需要分别为它们配置对应的事务管理器吗?它们到底是如何协作,如何工作的呢?这些层出不穷的问题往往压制了开发人员使用联合军种的想法。

其实,在这个问题上,我们低估了 Spring 事务管理的能力。如果您采用了一个高端 ORM 技术(Hibernate,JPA,JDO),同时采用一个 JDBC 技术(Spring JDBC,iBatis),由于前者的会话(Session)是对后者连接(Connection)的封装,Spring 会“足够智能地”在同一个事务线程让前者的会话封装后者的连接。所以,我们只要直接采用前者的事务管理器就可以了。下表给出了混合数据访问技术所对应的事务管理器:

表 1. 混合数据访问技术的事务管理器

混合数据访问技术 事务管理器
ORM 技术框架 JDBC 技术框架
HibernateSpring JDBC 或 iBatisHibernateTransactionManager
JPA Spring JDBC 或 iBatis JpaTransactionManager
JDO Spring JDBC 或 iBatis JdoTransactionManager

由于一般不会出现同时使用多个 ORM 框架的情况(如 Hibernate + JPA),我们不拟对此命题展开论述,只重点研究 ORM 框架 + JDBC 框架的情况。Hibernate + Spring JDBC 可能是被使用得最多的组合,下面我们通过实例观察事务管理的运作情况。

清单 1.User.java:使用了注解声明的实体类

import javax.persistence.Entity; 
import javax.persistence.Table; 
import javax.persistence.Column; 
import javax.persistence.Id; 
import java.io.Serializable; 
 
@Entity 
@Table(name="T_USER") 
public class User implements Serializable{ 
  @Id 
  @Column(name = "USER_NAME") 
  private String userName; 
  private String password; 
  private int score; 
   
 @Column(name = "LAST_LOGON_TIME") 
  private long lastLogonTime = 0;  
} 

再来看下 UserService 的关键代码:

清单 2.UserService.java:使用 Hibernate 数据访问技术

package user.mixdao; 
import org.springframework.beans.factory.annotation.Autowired; 
import org.springframework.jdbc.core.JdbcTemplate; 
import org.springframework.context.ApplicationContext; 
import org.springframework.context.support.ClassPathXmlApplicationContext; 
import org.springframework.stereotype.Service; 
import org.springframework.orm.hibernate3.HibernateTemplate; 
import org.apache.commons.dbcp.BasicDataSource; 
import user.User; 
 
@Service("userService") 
public class UserService extends BaseService { 
  @Autowired 
  private HibernateTemplate hibernateTemplate; 
 
  @Autowired 
  private ScoreService scoreService; 
 
  public void logon(String userName) { 
    System.out.println("logon method..."); 
    updateLastLogonTime(userName); //①使用Hibernate数据访问技术 
    scoreService.addScore(userName, 20); //②使用Spring JDBC数据访问技术 
  } 
 
  public void updateLastLogonTime(String userName) { 
    System.out.println("updateLastLogonTime..."); 
    User user = hibernateTemplate.get(User.class,userName); 
    user.setLastLogonTime(System.currentTimeMillis()); 
    hibernateTemplate.flush(); //③请看下文的分析 
  } 
} 

在①处,使用 Hibernate 操作数据,而在②处调用 ScoreService#addScore(),该方法内部使用 Spring JDBC 操作数据。

在 ③处,我们显式调用了 flush() 方法,将 Session 中的缓存同步到数据库中,这个操作将即时向数据库发送一条更新记录的 SQL 语句。之所以要在此显式执行 flush() 方法,原因是:默认情况下,Hibernate 要在事务提交时才将数据的更改同步到数据库中,而事务提交发生在 logon() 方法返回前。如果所有针对数据库的更改都使用 Hibernate,这种数据同步延迟的机制不会产生任何问题。但是,我们在 logon() 方法中同时采用了 Hibernate 和 Spring JDBC 混合数据访问技术。Spring JDBC 无法自动感知 Hibernate 一级缓存,所以如果不及时调用 flush() 方法将数据更改同步到数据库,则②处通过 Spring JDBC 进行数据更改的结果将被 Hibernate 一级缓存中的更改覆盖掉,因为,一级缓存在 logon() 方法返回前才同步到数据库!

ScoreService 使用 Spring JDBC 数据访问技术,其代码如下:

清单 3.ScoreService.java:使用 Spring JDBC 数据访问技术

package user.mixdao; 
import org.springframework.beans.factory.annotation.Autowired; 
import org.springframework.jdbc.core.JdbcTemplate; 
import org.springframework.stereotype.Service; 
import org.apache.commons.dbcp.BasicDataSource; 
 
@Service("scoreUserService") 
public class ScoreService extends BaseService{ 
  @Autowired 
  private JdbcTemplate jdbcTemplate; 
  public void addScore(String userName, int toAdd) { 
    System.out.println("addScore..."); 
    String sql = "UPDATE t_user u SET u.score = u.score + ? WHERE user_name =?"; 
    jdbcTemplate.update(sql, toAdd, userName); 
    //① 查看此处数据库激活的连接数 
    BasicDataSource basicDataSource = (BasicDataSource) jdbcTemplate.getDataSource(); 
    System.out.println("激活连接数量:"+basicDataSource.getNumActive()); 
  } 
} 

Spring 关键的配置文件代码如下所示:

清单 4. applicationContext.xml 事务配置代码部分

<!-- 使用Hibernate事务管理器 --> 
<bean id="hiberManager" 
  class="org.springframework.orm.hibernate3.HibernateTransactionManager" 
  p:sessionFactory-ref="sessionFactory"/> 
   
<!-- 对所有继承BaseService类的公用方法实施事务增强 --> 
<aop:config proxy-target-class="true"> 
  <aop:pointcut id="serviceJdbcMethod" 
    expression="within(user.mixdao.BaseService+)"/> 
  <aop:advisor pointcut-ref="serviceJdbcMethod" 
    advice-ref="hiberAdvice"/> 
</aop:config> 
   
<tx:advice id="hiberAdvice" transaction-manager="hiberManager"> 
  <tx:attributes> 
    <tx:method name="*"/> 
  </tx:attributes> 
</tx:advice> 

启动 Spring 容器,执行 UserService#logon() 方法,可以查看到如下的执行日志:

清单 5. 代码运行日志

12:38:57,062 (AbstractPlatformTransactionManager.java:365) - Creating new transaction 
  with name [user.mixdao.UserService.logon]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT 
 
12:38:57,093 (SessionImpl.java:220) - opened session at timestamp: 12666407370 
 
12:38:57,093 (HibernateTransactionManager.java:493) - Opened new Session 
  [org.hibernate.impl.SessionImpl@83020] for Hibernate transaction ① 
 
12:38:57,093 (HibernateTransactionManager.java:504) - Preparing JDBC Connection 
  of Hibernate Session [org.hibernate.impl.SessionImpl@83020] 
 
12:38:57,109 (JDBCTransaction.java:54) - begin 
 
… 
 
logon method... 
updateLastLogonTime... 
… 
 
12:38:57,109 (AbstractBatcher.java:401) - select user0_.USER_NAME as USER1_0_0_, 
  user0_.LAST_LOGON_TIME as LAST2_0_0_, user0_.password as password0_0_, 
 user0_.score as score0_0_ from T_USER user0_ where user0_.USER_NAME=? 
   
Hibernate: select user0_.USER_NAME as USER1_0_0_, 
 user0_.LAST_LOGON_TIME as LAST2_0_0_, user0_.password as password0_0_, 
 user0_.score as score0_0_ from T_USER user0_ where user0_.USER_NAME=? 
 
… 
 
12:38:57,187 (HibernateTemplate.java:422) - Not closing pre-bound 
  Hibernate Session after HibernateTemplate 
 
12:38:57,187 (HibernateTemplate.java:397) - Found thread-bound Session 
  for HibernateTemplate 
 
Hibernate: update T_USER set LAST_LOGON_TIME=?, password=?, score=? where USER_NAME=? 
 
… 
 
2010-02-20 12:38:57,203 DEBUG [main] (AbstractPlatformTransactionManager.java:470) 
  - Participating in existing transaction ② 
addScore... 
 
2010-02-20 12:38:57,203 DEBUG [main] (JdbcTemplate.java:785) 
  - Executing prepared SQL update 
 
2010-02-20 12:38:57,203 DEBUG [main] (JdbcTemplate.java:569) 
  - Executing prepared SQL statement 
 [UPDATE t_user u SET u.score = u.score + ? WHERE user_name =?] 
 
2010-02-20 12:38:57,203 DEBUG [main] (JdbcTemplate.java:794) 
  - SQL update affected 1 rows 
 
激活连接数量:1 ③ 
2010-02-20 12:38:57,203 DEBUG [main] (AbstractPlatformTransactionManager.java:752) 
  - Initiating transaction commit 
2010-02-20 12:38:57,203 DEBUG [main] (HibernateTransactionManager.java:652) 
  - Committing Hibernate transaction on Session 
 [org.hibernate.impl.SessionImpl@83020] ④ 
 
2010-02-20 12:38:57,203 DEBUG [main] (JDBCTransaction.java:103) - commit ⑤ 

仔细观察这段输出日志,在①处 UserService#logon() 开启一个新的事务,在②处 ScoreService#addScore() 方法加入到①处开启的事务上下文中。③处的输出是 ScoreService#addScore() 方法内部的输出,汇报此时数据源激活的连接数为 1,这清楚地告诉我们 Hibernate 和 JDBC 这两种数据访问技术在同一事务上下文中“共用”一个连接。在④处,提交 Hibernate 事务,接着在⑤处触发调用底层的 Connection 提交事务。

从以上的运行结果,我们可以得出这样的结论:使用 Hibernate 事务管理器后,可以混合使用 Hibernate 和 Spring JDBC 数据访问技术,它们将工作于同一事务上下文中。但是使用 Spring JDBC 访问数据时,Hibernate 的一级或二级缓存得不到同步,此外,一级缓存延迟数据同步机制可能会覆盖 Spring JDBC 数据更改的结果。

由于混合数据访问技术的方案的事务同步而缓存不同步的情况,所以最好用 Hibernate 完成读写操作,而用 Spring JDBC 完成读的操作。如用 Spring JDBC 进行简要列表的查询,而用 Hibernate 对查询出的数据进行维护。如果确实要同时使用 Hibernate 和 Spring JDBC 读写数据,则必须充分考虑到 Hibernate 缓存机制引发的问题:必须充分分析数据维护逻辑,根据需要,及时调用 Hibernate 的 flush() 方法,以免覆盖 Spring JDBC 的更改,在 Spring JDBC 更改数据库时,维护 Hibernate 的缓存。

可以将以上结论推广到其它混合数据访问技术的方案中,如 Hibernate+iBatis,JPA+Spring JDBC,JDO+Spring JDBC 等。

特殊方法成漏网之鱼

由于 Spring 事务管理是基于接口代理或动态字节码技术,通过 AOP 实施事务增强的。虽然,Spring 还支持 AspectJ LTW 在类加载期实施增强,但这种方法很少使用,所以我们不予关注。

对于基于接口动态代理的 AOP 事务增强来说,由于接口的方法是 public 的,这就要求实现类的实现方法必须是 public 的(不能是 protected,private 等),同时不能使用 static 的修饰符。所以,可以实施接口动态代理的方法只能是使用“public”或“public final”修饰符的方法,其它方法不可能被动态代理,相应的也就不能实施 AOP 增强,也不能进行 Spring 事务增强了。

基于 CGLib 字节码动态代理的方案是通过扩展被增强类,动态创建子类的方式进行 AOP 增强植入的。由于使用 final、static、private 修饰符的方法都不能被子类覆盖,相应的,这些方法将不能被实施 AOP 增强。所以,必须特别注意这些修饰符的使用,以免不小心成为事务管理的漏网之鱼。

下面通过具体的实例说明基于 CGLib 字节码动态代理无法享受 Spring AOP 事务增强的特殊方法。

清单 6.UserService.java:4 个不同修饰符的方法

package user.special; 
import org.springframework.stereotype.Service; 
 
@Service("userService") 
public class UserService { 
   
 //① private方法因访问权限的限制,无法被子类覆盖 
  private void method1() { 
    System.out.println("method1"); 
  } 
   
 //② final方法无法被子类覆盖 
  public final void method2() { 
    System.out.println("method2"); 
  } 
 
  //③ static是类级别的方法,无法被子类覆盖 
  public static void method3() { 
    System.out.println("method3"); 
  } 
   
 //④ public方法可以被子类覆盖,因此可以被动态字节码增强 
  public void method4() { 
    System.out.println("method4"); 
  } 
} 

Spring 通过 CGLib 动态代理技术对 UserService Bean 实施 AOP 事务增强的配置如下所示:

清单 7.applicationContext.xml:对 UserService 用 CGLib 实施事务增强

<?xml version="1.0" encoding="UTF-8" ?> 
<beans xmlns="http://www.springframework.org/schema/beans" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xmlns:context="http://www.springframework.org/schema/context" 
  xmlns:p="http://www.springframework.org/schema/p" 
 xmlns:aop="http://www.springframework.org/schema/aop" 
  xmlns:tx="http://www.springframework.org/schema/tx" 
  xsi:schemaLocation="http://www.springframework.org/schema/beans 
   http://www.springframework.org/schema/beans/spring-beans-3.0.xsd 
    http://www.springframework.org/schema/context 
   http://www.springframework.org/schema/context/spring-context-3.0.xsd 
 http://www.springframework.org/schema/aop 
 http://www.springframework.org/schema/aop/spring-aop-3.0.xsd 
 http://www.springframework.org/schema/tx 
 http://www.springframework.org/schema/tx/spring-tx-3.0.xsd"> 
 
  <!-- 省略声明数据源及DataSourceTransactionManager事务管理器--> 
  … 
  <aop:config proxy-target-class="true"> 
   <!-- ①显式使用CGLib动态代理 --> 
    <!-- ②希望对UserService所有方法实施事务增强 --> 
    <aop:pointcut id="serviceJdbcMethod" 
      expression="execution(* user.special.UserService.*(..))"/> 
    <aop:advisor pointcut-ref="serviceJdbcMethod" 
      advice-ref="jdbcAdvice" order="0"/> 
  </aop:config> 
  <tx:advice id="jdbcAdvice" transaction-manager="jdbcManager"> 
    <tx:attributes> 
      <tx:method name="*"/> 
    </tx:attributes> 
  </tx:advice> 
</beans> 

在 ① 处,我们通过 proxy-target-class="true"显式使用 CGLib 动态代理技术,在 ② 处通过 AspjectJ 切点表达式表达 UserService 所有的方法,希望对 UserService 所有方法都实施 Spring AOP 事务增强。

在 UserService 添加一个可执行的方法,如下所示:

清单 8.UserService.java 添加 main 方法

package user.special; 
import org.springframework.context.ApplicationContext; 
import org.springframework.context.support.ClassPathXmlApplicationContext; 
import org.springframework.stereotype.Service; 
 
@Service("userService") 
public class UserService { 
  … 
  public static void main(String[] args) { 
    ApplicationContext ctx = 
      new ClassPathXmlApplicationContext("user/special/applicationContext.xml"); 
     
 UserService service = (UserService) ctx.getBean("userService"); 
 
    System.out.println("before method1"); 
    service.method1(); 
    System.out.println("after method1"); 
 
    System.out.println("before method2"); 
    service.method2(); 
    System.out.println("after method2"); 
 
    System.out.println("before method3"); 
    service.method3(); 
    System.out.println("after method3"); 
 
    System.out.println("before method4"); 
    service.method4(); 
    System.out.println("after method4"); 
 
  } 
} 

在运行 UserService 之前,将 Log4J 日志级别设置为 DEBUG,运行以上代码查看输出日志,如下所示:

17:24:10,953 (AbstractBeanFactory.java:241) 
  - Returning cached instance of singleton bean 'userService' 
 
before method1 
method1 
after method1 
before method2 
method2 
after method2 
before method3 
method3 
after method3 
before method4 
 
17:24:10,953 (AbstractPlatformTransactionManager.java:365) 
  - Creating new transaction with name [user.special.UserService.method4]: 
 PROPAGATION_REQUIRED,ISOLATION_DEFAULT 
 
17:24:11,109 (DataSourceTransactionManager.java:205) 
  - Acquired Connection [org.apache.commons.dbcp.PoolableConnection@165b7e] 
 for JDBC transaction 
 
… 
 
17:24:11,109 (DataSourceTransactionManager.java:265) 
  - Committing JDBC transaction on Connection 
 [org.apache.commons.dbcp.PoolableConnection@165b7e] 
 
17:24:11,125 (DataSourceTransactionManager.java:323) 
  - Releasing JDBC Connection [org.apache.commons.dbcp.PoolableConnection@165b7e] 
 after transaction 
 
17:24:11,125 (DataSourceUtils.java:312) 
  - Returning JDBC Connection to DataSource 
 
after method4 

观察以上输出日志,很容易发现 method1~method3 这 3 个方法都没有被实施 Spring 的事务增强,只有 method4 被实施了事务增强。这个结果刚才验证了我们前面的论述。

我们通过下表描述哪些特殊方法将成为 Spring AOP 事务增强的漏网之鱼:

表 2. 不能被 Spring AOP 事务增强的方法

动态代理策略 不能被事务增强的方法
基于接口的动态代理除 public 外的其它所有的方法,此外 public static 也不能被增强
基于 CGLib 的动态代理private、static、final 的方法

不过,需要特别指出的是,这些不能被 Spring 事务增强的特殊方法并非就不工作在事务环境下。只要它们被外层的事务方法调用了,由于 Spring 的事务管理的传播特殊,内部方法也可以工作在外部方法所启动的事务上下文中。我们说,这些方法不能被 Spring 进行 AOP 事务增强,是指这些方法不能启动事务,但是外层方法的事务上下文依就可以顺利地传播到这些方法中。

这些不能被 Spring 事务增强的方法和可被 Spring 事务增强的方法唯一的区别在 “是否可以主动启动一个新事务”:前者不能而后者可以。对于事务传播行为来说,二者是完全相同的,前者也和后者一样不会造成数据连接的泄漏问题。换句话说,如果这些“特殊方法”被无事务上下文的方法调用,则它们就工作在无事务上下文中;反之,如果被具有事务上下文的方法调用,则它们就工作在事务上下文中。

对于 private 的方法,由于最终都会被 public 方法封装后再开放给外部调用,而 public 方法是可以被事务增强的,所以基本上没有什么问题。在实际开发中,最容易造成隐患的是基于 CGLib 的动态代理时的“public static”和“public final”这两种特殊方法。原因是它们本身是 public 的,所以可以直接被外部类(如 Web 层的 Controller 类)调用,只要调用者没有事务上下文,这些特殊方法也就以无事务的方式运作。

小结

在本文中,我们通过剖析了解到以下的真相:

混合使用多个数据访问技术框架的最佳组合是一个 ORM 技术框架(如 Hibernate 或 JPA 等)+ 一个 JDBC 技术框架(如 Spring JDBC 或 iBatis)。直接使用 ORM 技术框架对应的事务管理器就可以了,但必须考虑 ORM 缓存同步的问题;

Spring AOP 增强有两个方案:其一为基于接口的动态代理,其二为基于 CGLib 动态生成子类的代理。由于 Java 语法的特性,有些特殊方法不能被 Spring AOP 代理,所以也就无法享受 AOP 织入带来的事务增强。

在下一篇文章中,笔者将继续分析 Spring 事务管理的以下难点:

直接获取 Connection 时,哪些情况会造成数据连接的泄漏,以及如何应对;

除 Spring JDBC 外,其它数据访问技术数据连接泄漏的应对方案。

Tags:Spring 事务管理 高级

编辑录入:爽爽 [复制链接] [打 印]
赞助商链接