查询不需要事务控制
复杂的”修改+插入+删除“混合操作，需要事务控制，一般建议存储过程完成，可直接在存储过程中完成异常时候的回滚
所以最有可能需要事务处理的就是普通的插入、修改、删除（影响数据一致性的行为），这一部分是spring事务控制处理的核心部分
根据mvc设计建议，一般会在action层做业务流转处理，在service层做业务内容处理和调用，通过dao层获取数据模型，由于业务处理的核心多在service层，因此spring的事务管理一般多针对service进行配置，同样一些潜在业务处理异常的日志处理也都会在service产生，而在action层做一些异常跳转的处理，因此，常规做法：
1：在service层try catah各种业务异常，做异常返回结果处理，日志处理等
2：在action层捕获service层异常处理的结果，做异常跳转处理
但是这样一来，会产生冲突，spring配置的service层事务管理就是去了作用，为什么？因为默认spring只在发生未被捕获的runtimeexcetpion时才回滚，spring事务回滚要求抛出异常，如果try catch捕获了，spring没办法知道在哪里事务回滚了。
spring aop 异常捕获原理：被拦截的方法需显式抛出异常，并不能经任何处理，这样aop代理才能捕获到方法的异常，才能进行回滚，默认情况下aop只捕获runtimeexception的异常，但可以通过<tx:method name="upd*" propagation="REQUIRED" rollback-for="java.lang.Exception"/>配置来捕获特定的异常并回滚。换句话说在service的方法中不使用try catch 或者在catch中最后加上throw new runtimeexcetpion（），这样程序异常时才能被aop捕获进而回滚
怎样两者兼得呢，既能保证业务错误的到及时捕捉和日志记录，又能避免异常产生脏数据，让spring的事务管理起作用，综合查找网上的方案：
在service层需要事务控制的方法的catch语句中处理完业务日记操作后增加：
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()，手动回滚；或者在catch语句中最后增加throw new RuntimeException()语句再次抛出异常。
这样基本就可以解决大部分情况了，但是如果需要在catch异常时对数据库操作，那么spring不会区别这部分是有用功，一视同仁的清理掉了，所以这里要起另外一个事务来处理那些有用功，并且手动提交掉。也可以使用如下方法做处理：在service层上再套一层，该层不做事务控制，有用功就写在该层。需事务控制的仍保留在下层。
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource" /> </bean> <tx:advice id="txAdvice" transaction-manager="transactionManager"> <tx:attributes> <tx:method name="add*" propagation="REQUIRED" /> <tx:method name="upd*" propagation="REQUIRED" read-only="false" rollback-for="java.lang.Exception"/> <tx:method name="del*" propagation="REQUIRED" /> <tx:method name="*" propagation="SUPPORTS" /> </tx:attributes> </tx:advice> <aop:config> <aop:pointcut id="tranpc" expression="execution(* com.union.youtoo.manage.service.*.*(..))|| execution(* com.union.youtoo.www.service.*.*(..))"/> <aop:advisor advice-ref="txAdvice" pointcut-ref="tranpc" /> </aop:config>