除了经典的XA的支持，还值得提及的是WAS的一些特别的扩展。

    首先要介绍的是本地事务

    这儿先回顾一下为什么在EJB这种分布式计算模型下面为什么还有本地事务的需求。让我们先看一下在J2EE规范中明确提到了未指定的事务上下文这个概念。

    The term “an unspecified transaction context” is used in the EJB specification to refer to the cases in which the EJB architecture does not fully define the transaction semantics of an enterprise bean method execution:

    The execution of a method of an enterprise bean with container-managed transaction demarcation for which the value of the transaction attribute is NotSupported, Never, or Supports (onyl applies to the case when the client calls without a transaction context)

    The execution of the ejbCreate<METHOD>, ejbRemove, ejbPassivate, and ejbActivate methods of a session bean with container-managed transaction demarcation.

    The execution of the ejbCreate<METHOD> and ejbRemove methods of a message-driven

    bean with container-managed transaction demarcation.

    在上述提到的场景中，由于缺乏事务的语义，因此没有办法规定在这些场景下的事务属性。因此规范索性把这部分定义留给了具体的容器提供商。

    在这些情况下，WAS总是会启动一个本地事务（LTC）来对事务进行控制。LTC针对资源管理器的本地事务提供了三个层次的支持。首先是事务的边界，缺省是Bean方法；然后是对于没有完成的本地事务的处理策略，缺省是回滚。最后是对资源的回收，保证在本地事务推出时候里面所使用到得资源得以释放。

    LTC本身没有编程接口，只能通过WAS对EJB部署描述符的扩展来配置。

    分布式事务的一些扩展

    分布式事务上WAS也提供了两种扩展。

    第一种是Last participant。这种扩展用在一个事务中如果有多个资源管理器支持XA（2PC，两阶段），但恰好有一个只能支持RMLT （resource manager local transactions）（1PC，一阶段，没有Prepare，只有commit）的场景下。在这种情况下， 可以通过配置last participant来支持这种场景。具体实现上是在开始两阶段的prepare时，事务管理器首先询问其他的XA资源是否准备好，如果回答都是OK，接下来就调用1PC资源的提交，如果提交成功，则调用其他的2PC的commit，否则rollback。

    上面的场景要求只能有一个1PC的资源，如果把这个限制放松，则没有办法用这个方式来实现对不同类型的资源的统一协调。ActivitySession就是为了满足这种涉及了多个1PC的资源的应用场景。可以说它扩展了传统的XA的概念，把它延伸了道了1PC资源上。和分布式事务类似，它的事务边界的划分也可以通过声明式或者是编程来实现。但不同点在于它没有Prepare阶段，也没有Recovery。