非事务性出站如何与 Mule 中的事务性入站一起工作
How does a non transactional outbound work with a transactional inbound in Mule
在 transaction management 主题下的 Mule 文档中有一个神秘的段落
Mule can manage non-transactional outbound connectors. By default, an outbound connector from a non-transactional transport ignores an active transaction rather than rejecting it. In other words, the default transactional action for such connectors is no longer NONE. The example code below illustrates this behavior. Mule processes messages it receives from the VM queue synchronously and transactionally. The file transport in the code example is not transactional thus, writing to the file is not part of the transaction. However, if a message throws an exception while Mule is creating the file, Mule rolls back the transaction and reprocesses the message. This example is, in effect, a multiple resource transaction.
下面这句话是什么意思，是不是打错了（不再是NONE）？如果不是 NONE 那么交易行为是什么？
In other words, the default transactional action for such connectors is no longer NONE
另外，如果写入文件不是事务的一部分，那么如果文件写入失败，事务如何回滚？？
这不是打字错误。
以前，它曾经是 NONE，因此事务的解决独立于非事务性出站交互的结果。现在，事务没有解决，即非事务出站端点没有提交或回滚当前事务。
回滚是因为抛出异常，标记事务要回滚。当流程终止时，当前事务将被解决。如果已经标记回滚，则回滚，否则提交。
以上文本解释了 "Last Resource Gambit" 事务类型，其中除一个资源外的所有资源都是事务性的。在这种情况下，none 事务资源应该是最后一个，当它抛出异常时，所有其他事务资源都会回滚。
这是一种虚构的交易行为，非常有效。
更多信息在下面 link 的 "XA and the Last Resource Gambit" 部分：
http://www.javaworld.com/article/2077963/open-source-tools/distributed-transactions-in-spring--with-and-without-xa.html
在 transaction management 主题下的 Mule 文档中有一个神秘的段落
Mule can manage non-transactional outbound connectors. By default, an outbound connector from a non-transactional transport ignores an active transaction rather than rejecting it. In other words, the default transactional action for such connectors is no longer NONE. The example code below illustrates this behavior. Mule processes messages it receives from the VM queue synchronously and transactionally. The file transport in the code example is not transactional thus, writing to the file is not part of the transaction. However, if a message throws an exception while Mule is creating the file, Mule rolls back the transaction and reprocesses the message. This example is, in effect, a multiple resource transaction.
下面这句话是什么意思，是不是打错了（不再是NONE）？如果不是 NONE 那么交易行为是什么？
In other words, the default transactional action for such connectors is no longer NONE
另外，如果写入文件不是事务的一部分，那么如果文件写入失败，事务如何回滚？？
这不是打字错误。
以前，它曾经是 NONE，因此事务的解决独立于非事务性出站交互的结果。现在，事务没有解决，即非事务出站端点没有提交或回滚当前事务。
回滚是因为抛出异常，标记事务要回滚。当流程终止时，当前事务将被解决。如果已经标记回滚，则回滚，否则提交。
以上文本解释了 "Last Resource Gambit" 事务类型，其中除一个资源外的所有资源都是事务性的。在这种情况下，none 事务资源应该是最后一个，当它抛出异常时，所有其他事务资源都会回滚。 这是一种虚构的交易行为，非常有效。
更多信息在下面 link 的 "XA and the Last Resource Gambit" 部分： http://www.javaworld.com/article/2077963/open-source-tools/distributed-transactions-in-spring--with-and-without-xa.html