java - JTA 的真正交付值(value)是多少？

Question

我正在努力思考 Java Transactions API (JTA) 及其实现之一 Bitronix 下的值。但随着我越来越深入地研究文档，我不禁想到以下简单示例:

public interface Transactional {
    public void commit(Object);
    public void rollback();
}

public class TransactionalFileWriter extends FileWriter implements Transactional {
    @Override
    public void commit(Object obj) {
        String str = (String)obj;

        // Write the String to a file.
        write(str);
    }

    @Override
    public void rollback() {
        // Obtain a handler to the File we are writing to, and delete the file.
        // This returns the file system to the state it was in before we created a file and started writing to it.
        File f = getFile();

        // This is just pseudo-code for the sake of this example.
        File.delete(f);
    }
}

// Some method in a class somewhere...
public void doSomething(File someFile) {
    TransactionalFileWriter txFileWriter = getTxFW(someFile);
    try {
        txFileWriter.commit("Create the file and write this message to it.");
    } catch(Throwable t) {
        txFileWriter.rollback();
    }
}

不要太拘泥于上面的实际代码。这个想法很简单:一个创建文件并写入文件的事务文件编写器。 rollback() 方法删除文件，从而将文件系统返回到 commit(Object) 之前的状态。

我是不是漏掉了什么？这是 JTA 提供的全部吗？或者是否存在我上面的简单示例未表示的交易性的一组完全不同的维度/方面？我猜是后者，但尚未在 JTA 文档中看到任何具体内容。如果我遗漏了什么，那是什么，有人可以给我看具体的例子吗？我可以看到事务性是 JDBC 的一个重要组成部分，但希望能得到一个 JTA 与数据库以外的其他东西一起使用的例子。

Answer 1

正如其他人所提到的，JTA 的主要优势不是单个事务案例，而是多个事务的编排。

在适当的上下文中使用时，您的“交易文件”是一个优秀的概念性示例。

考虑一个人为设计的用例。

您正在上传一张具有关联元数据的图片，然后您希望提醒基础架构该文件已到达。

这个“简单”的任务充满了可靠性问题。

例如，这个工作流:

String pathName = saveUploadedFile(myFile);
saveMetaData(myFile.size(), myFile.type(), currentUser, pathName);
queueMessageToJMS(new FileArrivalEvent(user, pathName);

这段代码涉及文件系统和 2 个不同的服务器(DB 和 JMS)。

如果 saveUploadedFile 成功，但 saveMetaData 没有，您现在在文件系统上有一个孤立文件，可以说是“文件泄漏”。如果 saveMetaData 成功，但队列没有，您已经保存了文件，但“没有人知道”。交易的成功依赖于所有 3 个组件成功执行其任务。

现在，放入 JTA(不是真正的代码):

beginWork();
try {
    String pathName = saveUploadedFile(myFile);
    saveMetaData(myFile.size(), myFile.type(), currentUser, pathName);
    queueMessageToJMS(new FileArrivalEvent(user, pathName);
} catch(Exception e) {
    rollbackWork();
} finally {
    commitWork();
}

现在它“全部有效”，或者“都无效”。

通常人们会越过重重障碍使这种事情安全地工作，因为大多数系统没有事务管理器。但是使用事务管理器(即 JTA)，您的 TM 会为您管理所有的环，并且您可以保持代码干净。

如果您调查行业，您会发现交易经理很少。最初它们是“企业”等级系统使用的专有程序。 TIBCO是有名的，IBM有一个，微软有一个。燕尾服曾经很流行。

但是有了 Java、JTA 和无处不在的 Java EE(等)服务器，“每个人”都有一个事务管理器。我们在 Java 世界中“免费”获得此编排。而且它很方便。

Java EE 使事务管理器无处不在，事务处理成为后台考虑因素。 Java EE 意味着“永远不必再次编写 commit()”。 (显然 Spring 提供了类似的设施)。

对于大多数系统来说，这不是必需的。这就是为什么大多数人对它知之甚少，或者干脆不要错过它的原因。大多数系统填充单个数据库，或者根本不用担心围绕多个系统编排的问题。这个过程可能是有损的，他们已经建立了自己的清理机制，无论如何。

但是当你需要它的时候，它非常好。同时致力于多个系统可以解决很多令人头疼的问题。