当一个bean调用了setRollBackOnly()方法时，它是在向事务管理器询问何时结束将要回滚的当前事务。它将给它所参与的事务的结果一个选票。这些方法还存在于UserTransaction接口中，但由于大多数的bean都不访问这个接口，这些方法必须直接地在EJBContext中提供给bean。注意这个方法并不引发回滚操作，它只是简单地设置标志，表示事务在结束时应该回滚。不象JavaBan属性设置方法，这个方法不以boolean值作为参数。这个方法是特意设计成这样，以使得一个bean不能够改变另一个bean的回滚请求。一个bean也许希望使用getRoolBackOnly()方法，来检查当前的事务的状态。如果另一个bean已经标志这个事务为rollback，则正在调用的bean可以推测到并决定不能执行那些在、强制性达到操作，如数据库更新，而这些操作很有可能在事务结束时被反转过来。
客户划分的事务
尽管一个JEB厂商所必须的，大服务器厂商也许决定提供一个类，使得用户可以直接访问事务管理器。当需要在同一个上下文中在两个不同的服务器上调用bean时，用户也许会希望这样做。当然，每个bean的装配符可以允许这样的行为。用户可以创建一个事务，然后在两个不同server上的两个不同的bean上调用商务方法，而将事务的上下文也作为调用的一部分进行传递。一旦调用结束，用户将推测地结束事务。有container厂商产生的stub和skeleton将支持事务上下文的隐式传递。
这里是一个可能的例子：
Current current = new Current();
Current.setServiceProvider(txMgrURL);
Current.begin();
Current.doSomeWork();
RemRef1.doSomeWork();
RemRef2.doMoreWork();
Current.commit();
数据库操作的事务管理
bean当然希望使用JDBC来建立到数据库的连接，并在其上进行操作。但是，为了符合EJB这种container管理事务的模式，连接不能使用自动提交特性，并且不应该在连接上试图提交或回滚。
Container的角色是决定在这个事务中执行的所有行为应该提交还是回滚。这里提这样一个问题很好：container如何看到并管理由bean方法内部创建的数据库连接。尽管在规范中没有明确地提到，EJB将只能使用JDBC驱动，而JDBC也正是用来和EJB配合使用的。在数据库连接的创建时，驱动程序透明地将连接注册到正在执行的线程的当前事务中。之后当container决定结束事务时，数据库连接将自动地结束它。用OTS的术语说，数据库连接是不可恢复的资源，有事务服务在container的协助下，隐式地管理。尽管可以在这种情况下使用非事务感知的JDBC Driver，但开发者必须清楚任何在数据库连接上所做的操作都不属于bean的事务，开发者还必须确保在从方法返回之前结束数据库连接事务。试图使用SessionSynchronization接口来合并数据库连接事务和bean本身的事务是不可靠的，是