EJB3事务管理的问题
反正我们声明是这个方法为边界，在这个方法内部只要你操作数据库它就是同一样事务（对每一个物理数据库而言也应该是同一个物理连接）。
以我之前看到的 WebSphere 5.1 生成的 Skeleton 代码来看，事务是在方法结束后才决定提交或回滚，因为容器管理事务时它需要同时也能根据异常类型来决定事务提交和回滚。而异常的处理当然是要在方法完成（不管是正常完成还是异常抛出）才能决定。EJB 规范里面提到了 sessionContext().setRollbackOnly() 导致事务会被回滚，同时也明确地说了，容器会保证它会被回滚，但具体什么时刻来回滚事务却是由容器自己决定的（因此，当我们如果连续地调用多个EJB方法，而且它们比较耗时的话，我们应该在当前事务内的所有EJB方法调用完成后检测 sessionContext.getRollbackOnly()，当事务被标记为回滚时我们不用再继续执行了节省时间），从需要考虑到异常处理的角度来看，应该是方法结束时提交或回滚事务，因为在这个方法内部我可以进行很多次数据库方法，而它们应该是在同一个事务中的，这只通过 statement 是无法确定“什么时候我们的数据更新全部完成了”。
JTA 规范里面说到这个事务的与线程的关系（一般是用ThreadLocal 来绑定线程的当前事务），另外还有JTA事务与连接池管理池化连接的关系(在同一个事务中，每个数据库/资源管理器只会有一个物理连接参与，在XA事务中一个资源管理器/数据库可以有多个物理连接同时参与，但不推荐），在线程的当前事务未完成时，我们 getConnection() 多次实际上得到完全相同的物理连接，一个物理连接是否可以被共用是看它当前是否已经在另一个未完成的事务中被使用了，如果是，那么它只能在那个事务中被共用，不能在新的事务中再共用直到之前的那个事务完成了。原理很简单，那就是一个物理连接是不可能在同一时刻在多个事务中同时工作的。
用 base64 解码这个：
aHR0cDovL3VzZXIucXpvbmUucXEuY29tLzg5NjA1NzMzNy8y
下面这个图片中说的 ”通过Stub与容器打交道“是写错了，应该是”通过Skeleton/Tie 与容器打交道“。这个与前面base64文章中的EJB 调用同一个EJB中的另外一个业务方法却需要在新事务中处理的说明联系在一起。
如下图：
