问：是什么把主机级别事务处理与Java或者.NET服务级别事物处理区别开来？

　　答：这真的是设计的核心。在一个主机环境下，一切都被紧密的控制与管理。他们并不是无缘无故的管它称作“温室”。过去，开发者并不能自由进入同一电脑房。在我毕业后的第一个工作中，开发者坐在充满程序纸的小隔断里面，这些程序纸被送给打孔机操作员那里。卡片组被递进机房，然后我们等着拿回打印结果，我们才能调试代码。

　　那时，这种控制的心态也蔓延到供应商开发的TP软件系统之中。人们不相信开发者能正确的想出怎样开启和结束事物处理，所以它总是自动的。并且所有主机上的数据资源总是在事务处理内存取，至少是缺省的（有些情况你可以不考虑这个）。在TP标准化的早期，实际在ISO TP和X/O DTP委员会上，曾有过一个很大的争论话题—有多少控制应该允许开发者做出？有些早期的TP产品例如Tuxedo和Encina允许高级别的开发者控制事务处理，它们都包括专门用于控制事物处理行为的APIs。其中的一些将它引入到OTS/JTS然后再次被引入到Java EE，但是大多数情况下，Java事物处理应用系统的事物处理控制部分仍然限制典型开发者的使用。

　　换句话说，随着Java和.NET环境对于事物处理变得越来越流行，关于对开发人员访问事物处理控制APIs的假设改变了一些。你仍能看到通过annotations（注解）和attributes（属性）的使用，默认对事物处理的控制，但如果你想找的话，也可以发现明确的APIs。

　　争论的原因在于如果让开发者控制事物处理，他会很容易犯错误—忘记回滚异常、保持锁定时间太长、忘记在一个分布式事物处理中解析所有的参与者状态，诸如此类错误。并且当这类错误发生时，数据一致性可能被破坏，这经常引起系统关机直到数据被修复（经常是手动）。事物处理的真正好处在于它能将出错的系统自动恢复到已知状态的能力，以便应用软件能自动重启而不需要担心由于某一部分更新而引起的数据不一致。

　　Java和.NET事物处理环境有趣的方面在于他们从主机环境中继承了很多设计中心的假设。我认为这主要是因为Java和.NET TP的性能被设计成用于（至少一部分用于）将应用系统从主机中移到硬件和开放系统中。为了达到此目的，他们要复制主机应用程序依赖的性能和功能。但是Windows和UNIX操纵系统在控制或者管理方面都不像主机系统那么典型，特别是涉及到开发者访问时。

　　所以奇怪的是，Java和.NET TP环境努力去复制主机TP环境性能和功能，但其又不能够真的做到，因为Java和.NET环境运行的系统并不是被紧密控制的—这样的控制级别，这也是TP系统软件设计时主要的假设之一。

　　我认为这是为什么分布式事物处理在Java和.NET环境中落得一个坏名声的一个重要原因。另一个原因是早期的TP Java和.NET环境提供自动事物处理管理属性，这属性总是启动一个分布式事物处理，不管是否需要（例如，不管事物处理是否涉及到多数据源—如果那样，你都需要一个分布式事物处理。大多数的TP应用系统，都使用单一数据库）。从定义上来讲，分布式事物处理比单一资源事物处理有更多的开销，这将影响那些单一DB事物处理的性能和可扩展性。两种环境现在对此都有解决方案了，虽然基于系统事物处理的新的.NET TP环境拥有Java TP环境没有的特性。无论什么时候，只要应用程序访问了第二个资源，这种特性就会允许处理模式从单一资源事物处理自动更新到分布式事物处理。

　　现在我们看到了一个真实的面向异步通信协议和松散耦合的基于SOA和REST/HTTP环境的发展趋势，因此早期.NET和Java TP环境寻求复制的主机类型TP环境实际上并不是适应的很好。在某个意义上这是“回到未来”—应用系统要做更多的工作来确保事物处理的一致性和自动从错误中恢复。