Apache Commons Transaction实现的文件事务

http://commons.apache.org/transaction/

有这么一个东西，其中的file包用来实现文件事务，不过具体实现方式实在不敢恭维。它完全依靠文件系统来保证它的事务，例如，它假设文件的删除、覆盖操作是一个原子操作，这样，当一个事务要修改任何一个文件的时候，它都是给你一个OutputStream，这个流输出到一个临时目录。提交的时候，它把用临时目录中的文件覆盖真正的文件。

也就是说，它不支持随机写
，假如有一个10M的文件（或者100M或者更大），哪怕一个事务中只修改一个字节，也要写10M，性能实在很差。如果仅仅是这样，对于
很多对性能没有要求的应用来说，应该还是不错的。

但它好像还有更多的问题。可以做一个实验，大致如下：
try{
  开始事务
  删除文件1
  删除文件2
  提交
}catch(){
  回滚
}
我们用点手段锁住文件2，让这个文件删不掉，然后运行这个程序，同时结合源代码进行跟踪，并观察存储目录和临时工作目录的文件情况。结果发现：
1、提交的时候，当删除第一个文件的时候，它并没有把文件1复制到临时工作目录。文件1真的被删除了，这样当删文件2出错的时候，回滚是不可能的。
2、当删除文件2出错，并且代码执行到回滚的时候。真的出现了异常，说是数据库已经处于dirty的状态，不能操作了。这种情况等于是需要手工干预了。这个时候文件1被删除，文件2还在。
3、解除文件2的锁定，下次重启FileResourceManager的时候，会尝试进行恢复，结果是两个文件都被删掉。如果没有解除锁定，重启 FileResourceManager还要出错。

我觉得是非常不应该的，这样就机会没法用了，不知道他们怎么想的，还是我弄错了？

评论

2 楼 webwiki 2011-12-27  

不好意思，刚才想当然的说了一下，试了试发现说错了，补充一下：
1）应该这么判断：
                        frm.startTransaction(txId2);
frm.deleteResource(txId2, resId1);
frm.deleteResource(txId2, resId2);
int vote = frm.prepareTransaction(txId2);
System.out.println(vote);
if (vote == FileResourceManager.PREPARE_SUCCESS) {
frm.commitTransaction(txId2);
} else {
frm.rollbackTransaction(txId2);
}
2）确实锁定了文件2时，commit会失败（实际上这个事务还未真正完成）。在提交失败后，一旦文件锁获得释放，就可以通过frm.recover()操作最终完成这个事务，保证事务的完整性。

webwiki 写道

看你写的挺认真的，但是分析的却很不得法，你大概是不太了解两阶段事务的概念。这个要这么写才对，如下：

try{
  开始事务
  删除文件1
  删除文件2
  int vote =   prepare()
  if(vote==XAResource.XA_OK){
    提交
  } else {
    回滚
  }
}catch(){
  回滚
}

这个项目做的还是挺好的，至少不至于连这么简单的问题都弄不好，否则那还有人用啊。

1 楼 webwiki 2011-12-27  

看你写的挺认真的，但是分析的却很不得法，你大概是不太了解两阶段事务的概念。这个要这么写才对，如下：

try{
  开始事务
  删除文件1
  删除文件2
  int vote =   prepare()
  if(vote==XAResource.XA_OK){
    提交
  } else {
    回滚
  }
}catch(){
  回滚
}

这个项目做的还是挺好的，至少不至于连这么简单的问题都弄不好，否则那还有人用啊。