Java transaction笔记(二)

续Java transaction笔记(一， 继续我的transaction之旅。这次是XA transaction.

Wiki对于XA的描述



在j2ee中，典型的应用场景是在同一事务中应用db和jms,或是不同的db.

    public void doSometing()
    {
        updateDatabase();
        sendJMSMessage();
    }

在非XA应用中，message一旦被发送至queue或topic，则会立即被接受方消费。所以即使updateData()出错，整个doSometing()需要回滚时，sendJMSMessage()已经提交无法再回滚了。

如果应用了XA，则message一直被保持在queue中直至整个事务提交。

XA的要求
对于jms来说，需要配置支持XA的 connection factory.
对于db来说，需使用支持XA的JDBC driver.

两阶段提交(2 phase commit)
先说transaction的管理，如下图。

transaction manager与不同的resource manager都有交互。

在phase1时，transaction manager向两个resouce询问是否可以准备提交。Resouce可回复ready, not_ready或是read_only. 当两个都ready时，则可以进入phase2 进行提交。任何一个回复not_ready则整个transaction 回滚。回复read_only的资源在phase2阶段被排除在提交过程之外。


Last resource commit optimization
有app server可以允许非XA的资源加入到XA的事物中来。简单说来，就是在phase1 XA的资源发送ready 讯号给transaction manager，则立即对非XA的资源进行commit，一旦它成功提交，再对XA的资源进行phase2 提交。 倘若在这个过程中，非XA的资源commit时出错，在phase2 所有的XA的资源都会收到rollback的请求.

当然使用LRCO的问题也还是有的，首先是不同的server对此可能有不同的实现，那么移植将是一个问题。其次就是 使用它会导致 heuristic exception出现的概率上升。

Heuristic exception一般出现于phase1两个资源可能有的timeout.

总结
使用XA是一件比较麻烦的事，特别是有可能出现一些在local transaction中没有见过的错误，譬如heuristic exception. 还有一个限制，就是在db的procedure中不能出现DDL.

除非你确实需要在同一个事务中管理多个资源，否则尽量选择其他方案。举个例子，有一个EJB需要横跨两个db进行查询，在非XA的情况下，可以第二个db的访问转移到一个local bean的方法中，并将这个方法的事务属性声明为 not supported.