解决思路：这种错误出现在久经考验的框架当中，我心里是相当不安的，居然会有这种低级趣味的错误。整理思路开始分析：这段代码唯一与以前不同的地方就是，我们在web应用中，是通过容器加载提供bean的，只有容器启动的时候才会加载xml。那么重点就应该是关注XML的加载方式了。
在这里我们用的是ApplicationContext接口。注意看spring文档3.5.1.2.2 在非web应用中优雅地关闭springioc容器。它这里用到的是AbstractApplicationContext，在取得bean后，再执行一个context.registerShutdownHook();
这里实验一把，将ApplicationContext改成AbstractApplicationContext，执行context.close()。结果出来了，session已被正常回收，真相渐渐浮出水面。

结论：每次加载context的做法相当于每次都生成了一次新的spring容器，在默认单例的情况下，如果不及时关闭context。service所依赖的DAO当中创建的dataSource也一直存在（包括所有的单例情况下所生成的类)，从日志看，service事务管辖中的session确实已经关闭，但SessionFactory还是存在的。只有在容器关闭的情况下，并指定了dataSource实例配置中的destroy-method="close"，dataSource单例才会被释放。
spring文档当中对生命周期也描述的很清楚。通过DisposableBean或者指定destroy-method都能很好的释放单例对象。而prototype类型的对象需要客户端显式的指定释放，释放对象完全是客户端控制,spring不负责释放。
所以，要改善context的加载方式，尽量的少多次去加载，实在没办法的情况下，一定要记得关闭。
最后，写代码的随意性，图省事，不经思考，是造成这种BUG的罪恶根源。

是缺乏一个所见即所得的编辑器。而这次，这些烦恼彻底解决。XMLmind XML Editor!第一次发现它的时

候有点相见恨晚的感觉，它让我的文档写的如此轻松。
不过有一点要注意，在官网下载的XMLmind XML Editor个人版是不支持直接将xml生成的html,pdf等格式

的。还好，目前有xsltproc，fop，openjade这些工具支持，有了这些在windows下也可以转换的工具，生

成其他格式也不是什么难事。我目前就使用xsltproc来生成html。

附上XMLmind XML Editor的下载地址http://www.xmlmind.com/xmleditor/persoedition.html
附加上xsltproc的下载地址 http://www.zlatkovic.com/pub/libxml/
再附上docbook的地址http://www.oasis-open.org/docbook/

之前的麻烦统统消失，那么剩下的就是享受它的好处了。

不用word，文档也可以写的这么漂亮。docbook，看第二眼发现你依然还是那么好。

但是我们在某种使用场合的过程中，为什么有时事务处理老是不起作用呢？这里,为您道出原因之一,

首先请看一段话

Spring的事务实现采用基于AOP的拦截器来实现，如果没有在事务配置的时候注明回滚的checked exception，那么只有在发生了unchecked exception的时候，才会进行事务回滚。

有必要先解释一下checked exception与unchecked exception：

先看看EXCEPTION在JDK文档当中的结构

java.lang.Object

  java.lang.Throwable

      java.lang.Exception

          java.lang.RuntimeException

而Unchecked exception: 这类异常都是RuntimeException的子类，虽然RuntimeException同样也是Exception的子类，但是它们是特殊的。Exception是作为checked Exception 出现的。

所以，除了Error与RuntimeException，其他剩下的异常都是你需要关心的，而这些异常类统称为Checked Exception

有了以上的基础，看看我们框架当中的事务属性

<property name="transactionAttributes">

                     <props>

                            <prop key="get*">PROPAGATION_REQUIRED,readOnly </prop>

                            <prop key="save*">PROPAGATION_REQUIRED </prop>

                            <prop key="delete*">PROPAGATION_REQUIRED</prop>

                            <prop key="update*">PROPAGATION_REQUIRED </prop>

                     </props>

</property>

此处，我们没有指定任何异常，那么它目前默认处理的就是unchecked exception了，再结合我们自身每个项目的模块，在我们的每个项目当中几乎都定义了自己的异常，这些异常都是继承自Exception，很不幸的是，我们继承的Exception包括自己定义的异常，都是checked exception。

所以，在我们的事务处理机制当中，事务不管用了。

解决办法有2个：

1，在事务属性后面加上需要回滚的checked exception。比如<prop key="save*">PROPAGATION_REQUIRED,-XXXXException</prop>(注意那个"-",对应的是"+")

2, 不改配置文件，将需要事务回滚的异常继承自unchecked exception类，也就是RuntimeException。

(nighthawk)

          前面提到的另一个版本则是需要基于JBOSS环境的完全版。它的配置相对于Embeddable来说更简单一些。   实际上针对这个版本的web应用当中调用EJB3 是无需任何额外配置的.
然而在此之前我走了一段弯路：
比如看到网上一些介绍性的文章当中提到需要将{jboss_home}\client 当中的一些包拷到web-inf\lib的下面，然后在初始化InitialContext时需要加上java.naming.factory.initial，java.naming.factory.url.pkgs等等的参数。这样反而会抛出CommunicationException: Receive timed out异常。实际上JBOSS都已经将初始化环境设置好了。
以下实例是web环境下调用jboss 下ejb3的客户端：
http://www.myjavaserver.com/~nighthawk/EJBClient.war
部署在jboss下的ejb3例子，以上2个客户端都是调用的它：
http://www.myjavaserver.com/~nighthawk/MyEJB.jar
web环境下调用Embeddable ejb的客户端的实例比较大，空间不够，不往上放了。
不过配置起来也很简单，只需将Embeddable版本当中的conf与lib包放在war包的classed与lib下即可。
以上例子均在jboss-4.0.4.GA下测试过。
                                                                                                                              ©2006 nighthawk.All rights reserved