Weblogic执行transaction recover碰到的奇怪问题

核心提示： 如果这两个事务分支分别指向不同的database的话，global prepare时，Weblogic执行transaction recover碰到的奇怪问题(4)，xaResource.prepare()的结果应该为OK(prepare的时候，database工作正常)，对于Emulate 2

如果这两个事务分支分别指向不同的database的话，global prepare时，xaResource.prepare()的结果应该为OK(prepare的时候，database工作正常)。而我们上面的测试中，因为操作的是统一database，其prepare的结果分别是：OK, READ_ONLY(数据库端认为该TX branch对应的操作不涉及数据修改)。返回READ_ONLY的时候，因为database认为该 tx branch不涉及数据修改，所以直接将它commit了。这也就解释了上面的疑问，global commit没有执行的时候，怎么就有tx branch被commit了。

下面再看看，为什么tlog中只能看到check point信息，而没有记录tx信息。在global prepare中，所有的参与该tx的resource的prepare结果返回后，weblogic需要根据vote结果决定进行global commit or global rollback。如果所有resource prepare都没问题的话，则将进行global commit。而在global commit之前，weblogic需要判断是否要将该tx信息记录到tlog中，而是记录tx的依据就是vote结果为0(OK)的resource个数是否大于1。大于1，则记入tlog，否则不做记录。我们上面的测试中，因为只涉及两个resource，而这两个resource的vote结果分别为：0(OK), 3(READ_ONLY)，所以该tx信息没有被记录到tlog中。

weblogic在recover的时候，首先检查tlog中的tx信息，如果存在tx，则读取tx信息，并将该tx放入到当前 server的txMap中。然后调用xaResource.recover()，该方法的执行结果是，resource manager(如database, jms server)返回自己手里的pending transaction的xid list。 weblogic遍历该xid list，如果发现某个xid在当前txMap中，则忽略它(该tx将会被其他线程commit)，那些不在txMap中的xid将会被 rollback，通过xaResource.rollback(Xid xid)实现。在我们上面的测试中，因为tx没有被记录到tlog中，所以weblogic在recover的时候会将database返回的xid: 0000669563242B7A1CFC-4F726163656C58414453 rollback。由于Oracle Driver的特殊处理，两个connection上的两个tx branch被合并成了一个branch(另一个被它认为是个READ_ONLY)，所以在rollback的时候，test, test1两表上的数据都被rollback了。

在使用两个不同的database测试中，能够看到tlog中的tx信息，weblogic server重启后，也能看到tx的commit。tlog信息如下：

图片看不清楚？请点击这里查看原图（大图）。

最后再说一下weblogic执行global prepare时，resource的prepare顺序：

1：remote xa resource

2：local xa resource

3：non-XA resource( LLR，对于Emulate 2PC的nonXA reosurce, 它的prepare结果直接就是OK，其实是个假prepare)

所谓的remote, local不是只resource managed的位置，而是指resource对应的coordinator的位置。