记录一次java ssm框架下数据回滚问题以及解决方法

记录一次数据回滚问题以及解决方法

离线写博客

最近一个spring+spring mvc+mybatis项目中遇到一个数据插入后，事务等待超时，导致数据回滚，页面幻读问题
事务配置：

"transactionAdvice" transaction-manager="transactionMapper">  
          
            "insert*" propagation="REQUIRED" isolation="SERIALIZABLE" rollback-for="java.lang.Exception"/>
             "add*" propagation="REQUIRED" isolation="SERIALIZABLE" rollback-for="java.lang.Exception"/>  
            "update*" propagation="REQUIRED" isolation="SERIALIZABLE" rollback-for="java.lang.Exception"/>  
            "delete*" propagation="REQUIRED" isolation="SERIALIZABLE" rollback-for="java.lang.Exception"/>  
            "get*" propagation="SUPPORTS" read-only="true" />  
            "find*" propagation="SUPPORTS" read-only="true" />  
            "select*" propagation="SUPPORTS" read-only="true" /> 
            "*" propagation="REQUIRED" isolation="REPEATABLE_READ" rollback-for="java.lang.Exception"/>   
          
     

错误日志记录的异常是：

Caused by: java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction
    at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1094)
    at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4208)
    at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4140)
    at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2597)
    at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2758)
    at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2826)
    at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2082)
    at com.mysql.jdbc.PreparedStatement.execute(PreparedStatement.java:1302)
    at com.alibaba.druid.filter.FilterChainImpl.preparedStatement_execute(FilterChainImpl.java:2929)
    at com.alibaba.druid.filter.FilterEventAdapter.preparedStatement_execute(FilterEventAdapter.java:440)
    at com.alibaba.druid.filter.FilterChainImpl.preparedStatement_execute(FilterChainImpl.java:2927)
    at com.alibaba.druid.filter.FilterAdapter.preparedStatement_execute(FilterAdapter.java:1058)
    at com.alibaba.druid.filter.FilterChainImpl.preparedStatement_execute(FilterChainImpl.java:2927)
    at com.alibaba.druid.proxy.jdbc.PreparedStatementProxyImpl.execute(PreparedStatementProxyImpl.java:118)
    at com.alibaba.druid.pool.DruidPooledPreparedStatement.execute(DruidPooledPreparedStatement.java:493)
    at sun.reflect.GeneratedMethodAccessor88.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.apache.ibatis.logging.jdbc.PreparedStatementLogger.invoke(PreparedStatementLogger.java:59)
    at com.sun.proxy.$Proxy279.execute(Unknown Source)
    at org.apache.ibatis.executor.statement.PreparedStatementHandler.update(PreparedStatementHandler.java:46)
    at org.apache.ibatis.executor.statement.RoutingStatementHandler.update(RoutingStatementHandler.java:74)
    at org.apache.ibatis.executor.SimpleExecutor.doUpdate(SimpleExecutor.java:50)
    at org.apache.ibatis.executor.BaseExecutor.update(BaseExecutor.java:117)
    at org.apache.ibatis.executor.CachingExecutor.update(CachingExecutor.java:76)
    at org.apache.ibatis.session.defaults.DefaultSqlSession.update(DefaultSqlSession.java:198)
    at sun.reflect.GeneratedMethodAccessor4906.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:434)
    ... 71 more

锁等待超时，初步猜测问题，是因为事务配置的隔离级别是串行化，我的理解是，事务排队一个一个按顺序提交，所以同一个时间段对数据库增删改操作过多时，等待时间过长，所以报了“Lock wait timeout exceeded; try restarting transaction”，一不做二不休直接将事务的配置注释掉，再次测试，在多个人同时操作时，再次发生了数据回滚，猜测是否事务依然存在，没有被注释掉，于是乎自己写了一个测试方法，对数据库进行插入操作后throw new Exception，抛出一个异常，测试事务是否依然存在，并回滚数据。

然而测试之下，数据并没有回滚，说明配置的事务已经注释掉了，那之前发生的回滚问题是何处导致的呢？在翻遍所有java，xml文件后发现，在某个sql映射的xml文件中发现了SET AUTOCOMMIT=0;后在sql末尾commit，标注一下AUTOCOMMIT=0时sql需要手动提交，所以问题找到了，这是一种很不合理的写法，因为已经使用了数据库连接池，没必要在使用这种方式，而且并发性十分的差，俩个人操作时都会导致锁等待，因为sql结束时也没有把AUTOCOMMIT 改为1，所以以后调用的sql都不会提交，所以一直等待，到错过了默认超时时间，就会报出异常，数据回滚

总结：对事务的使用，要视情况而定，如在夸数据源时，事务就无法起效果，且锁一定要慎用。