SSM整合中遇到的问题总结

最近在用SSM框架，使用过程中遇到的问题，就本博客做一个总结：

1.struts2不是所有情况下都支持pojo的

struts2本身是支持pojo的，即当以account.name形式的参数进行http访问的时候，可以自动封装成对象。

但是表单中有一个enctype属性，该属性指定了表单数据的编码格式：

默认格式为：application/x-www-form-urlencoded,它将表单域的值处理成url编码。这种编码格式，web服务器会替我们处理底层的二进制流，并将二进制转换成对应参数请求值。此时可以支持pojo

当上传文件时，我们会将enctype设置为mutipart/form-data，此时struts2不再支持pojo，参数也不再能用request.getparameter获取。struts2默认使用的是Common-FileUpload框架，它可以将对应参数封装到action类中相同参数名的参数中，String类型的参数可以直接获取，File参数则需要使用文件流读取。

2.Spring和struts2整合后的线程安全问题。

struts2本身是线程安全的，为每一个线程提供一个action实例，但spring的依赖注入默认采用的是单例模式，所以当我们注入action的时候，一定要声明scope=“prototype”或者scope=“session”，如果采用单例，则下次访问会受上次访问时内存中值得影响

scope=“prototype”是为每个请求提供一个action实例(与struts2的机制是一样的)。
scope=“session”是为每个会话提供一个action实例。

推荐使用scope=“prototype”，scope=“session”会占用服务器较多资源。

3.Mybatis的返回值问题

当Mybatis执行update ，insert，delete语句时，会返回一个int型数据，该数据表示的是数据库中数据有效修改的行数。故可以用来校验数据库是否按计划更新。

4.Spring定时任务

Spring定时任务采用的是多线程的机制，它并不像我们写一个线程然后采用sleep的方式去定时执行某些任务，所以存在多线程安全问题。比如说：当你需要它定时去从数据库中select一些数据，做一些处理后，然后再进行update操作。如果定时任务时间间隔较短，会造成线程1的还没有update,线程2的又进行了select,从而造成数据重复处理。

增大定时任务时间间距，并不是一种保险的做法，可以采用java的synchronized给方法加锁，从而保证线程安全

5.当采用Spring做了action的依赖注入，action配置文件中一定要采用Spring配置的actionbean的名称，这个相当如容器的入口，如果依然用详细地址做配置，action中凡是使用Spring注入的元素都会报空指针异常。