Project configuration
struts+spring+ibatis
Websphere+as400+db2
problems encountered
Click a button on the web page, call the back-end business logic, and then access the database through dao to perform various transaction operations (add, delete, modify, check, etc.), but the same operation, the same data, sometimes fails occasionally, by viewing Log file, found that the root cause is the following exception.
StaleConnectionException, the reason is that the db connection in use is a failed connection. And there is no regularity in the time when the exception occurs.
Caused by:
com.ibm.websphere.ce.cm.StaleConnectionException: [SQL0901] SQL system error.
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:80)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57)
at java.lang.reflect.Constructor.newInstance(Constructor.java:539)
at com.ibm.websphere.rsadapter.GenericDataStoreHelper.mapExceptionHelper(GenericDataStoreHelper.java:621)
at com.ibm.websphere.rsadapter.GenericDataStoreHelper.mapException(GenericDataStoreHelper.java:680)
at com.ibm.ws.rsadapter.AdapterUtil.mapException(AdapterUtil.java:2267)
at com.ibm.ws.rsadapter.jdbc.WSJdbcUtil.mapException(WSJdbcUtil.java:1191)
at com.ibm.ws.rsadapter.jdbc.WSJdbcPreparedStatement.execute(WSJdbcPreparedStatement.java:635)
at sun.reflect.GeneratedMethodAccessor111.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:613)
at com.ibatis.common.jdbc.logging.PreparedStatementLogProxy.invoke(PreparedStatementLogProxy.java:62)
at com.sun.proxy.$Proxy29.execute(Unknown Source)
at com.ibatis.sqlmap.engine.execution.SqlExecutor.executeQueryProcedure(SqlExecutor.java:289)
at com.ibatis.sqlmap.engine.mapping.statement.ProcedureStatement.sqlExecuteQuery(ProcedureStatement.java:34)
at com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryWithCallback(GeneralStatement.java:173)
at com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryForObject(GeneralStatement.java:104)
at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject(SqlMapExecutorDelegate.java:561)
at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject(SqlMapExecutorDelegate.java:536)
at com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryForObject(SqlMapSessionImpl.java:93)
at org.springframework.orm.ibatis.SqlMapClientTemplate$1.doInSqlMapClient(SqlMapClientTemplate.java:210)
at org.springframework.orm.ibatis.SqlMapClientTemplate.execute(SqlMapClientTemplate.java:168)
at org.springframework.orm.ibatis.SqlMapClientTemplate.queryForObject(SqlMapClientTemplate.java:208)
various countermeasures
I checked various solutions on the Internet, but the problem is still not solved after the trial. Finally, after reading the official documentation of ibm, the problem is locked to the database connection pool of ibm. The connection in the database connection pool of ibm cannot be guaranteed to be valid 100%. connection, but once an invalid connection is obtained, the next connection obtained must be a valid connection. There are two recommended methods:
Option A: Before executing the business sql each time, call a test sql to test whether the connection is valid, and then execute the business sql if it is valid, but obviously this will reduce the efficiency, and the key is that after the trial, it does not solve our problem The problem, because the trigger timing of StaleConnectionException is very random, the connection is easy to use when testing sql, but it will suddenly become invalid in the middle of executing business sql, so it will still fail.
Solution B: Solve the problem at the application level. When the action calls the service to start transaction processing, if a StaleConnectionException occurs, then we call the service again, which is equivalent to retrying, because the ibm connection pool can ensure that after obtaining an invalid connection, then The obtained connection must be a valid connection. Of course, the number of retries can be determined by yourself. Generally, it is OK to retry once. If there are too many times, the front-end page will be significantly slower.
Therefore, we finally chose option B. Do it yourself, and when the front end is not aware of it, the back end retries the service call again.
For specific implementation, please refer to
Using AOP to realize the re-invocation of business services (2)