一年前，我们项目最开始使用的SSH(spring+springmvc+hibernate)，那时候项目经理搭建好了框架就交给了我们，后来在一次配置事务的过程中，出现了大名鼎鼎的no seesion。
网上查都是说事务没配置好，我选了好几种事务配置方法，其中只有注解有效，AOP切面配置事务都报错。
说实话一开始就走歪了，那时候不理解spring和springMVC的关系，web.xml配置文件都是这样：
<context-param>
<param-name>contextConfigLocationparam-name>
<param-value>classpath*:config/spring-*.xmlparam-value>
context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListenerlistener-class>
listener>
<servlet>
<servlet-name>springMVCservlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServletservlet-class>
<init-param>
<param-name>contextConfigLocationparam-name>
<param-value>classpath*:config/spring-servlet.xmlparam-value>
init-param>
<load-on-startup>1load-on-startup>
servlet>
<servlet-mapping>
<servlet-name>springMVCservlet-name>
<url-pattern>/url-pattern>
servlet-mapping>观察就会发现，上面的spring配置文件已经包含了对springMVC配置的检索，这样不仅是重复读取配置文件的问题还会带来其它的隐患。
另外一个就是扫描包的范围配置，spring应该扫描哪些，springMVC应该扫描哪些，或者说应该排除哪些包的扫描。
那次的问题折腾了比较久，记得连续两个晚上下班回家都在研究，虽然表面看起来是事务的配置问题，如果你老是纠结于事务的配置方法就跑偏了。
我当时就想，为什么注解没有问题，而xml配置事务就会报错，肯定是配置有问题，但是这个事务的配置都是参考网上的，大都是这么配的。
然后我干脆在service类中用静态代码块打印语句，看这个service到底加载了几次，通过这个方法我发现启动的过程中一个service打印四次语句，网上查阅配置事务后会生成代理类什么的，所以打印两次是没有问题的，而四次说明这个类重复加载了。
param>
<param-name>contextConfigLocationparam-name>
<param-value>classpath*:config/springMVC-servlet.xmlparam-value>
param>我把web.xml中springMVC的配置文件改成上面的样子，然后在spring扫描包范围内排除对springMVC的扫描，我还发现事务竟然一部分配置在spring的配置文件里，还有一部分配置在springMVC的配置文件里，我把它们都移动到了spring配置文件中，反正就是各种尝试，目的就是让service仅仅加载一次。
没想到最后竟然成功了，现在回忆起当时的那种兴奋，不可言状。但是究竟是什么原因，我是通过交叉操作，不断变换配置，才锁定了问题所在。
总结一下错误的原因：
1. spring在contextConfigLocation中因为通配符问题读取了springMVC的配置文件。
2. springMVC配置文件中配置了事务，但是第一次因为是spring直接处理的，它能读取所有配置文件，所以即使放在不同的配置文件里也能成功。
3. 当springMVC再次针对它自己的配置文件来处理时，只能看到事务的部分配置，所以事务配置不成功，no session !
有一段时间没用SSH框架了，昨天一个朋友又遇到类似问题，使我想起来了，这里还是记录下，以后理解得更透彻了，将会继续补充。
对于spring和springMVC的整合，我觉得要注意下面几点：
1. 不要太相信网上的东西，很多人只是能跑就行，没有真正理解。
2. 要搞清楚spring和springMVC在一起的时候，各自充当了什么角色。
3. springMVC的配置文件其实也是依靠spring来解析并做相应处理的。
4. 两者的上下文环境有什么关系。