轉載：http://13594135.iteye.com/blog/904913

一次做應用升級出現了一個問題，描述如下：
   升級分為兩塊，一塊是資料庫結構變更（表結構增加新欄位）;一塊是應用程式的升級。
   應用環境為：jboss4.0.5 +　ibatis + spring 資料來源在jboss的oracle-ds.xml檔案中進行配置，透過spring的jndi方式進行查詢。
   我先將資料庫進行升級，更改表結構（增加欄位），因為應用中的ibatis的查詢採用的是ResultMap返回方式，返回定義的表結構欄位，即使資料庫發生變更，也不會產生影響。於是我大膽的進行指令碼的執行。結果當我下午16:00資料庫變更之後，幾乎在同時就有人反應應用的一些查詢功能無法使用，立刻檢視出錯日誌：
Java程式碼

   1.    Caused by: com.alibaba.generalorm.dao.DataAccessException: Data query error!
   2. --- The error occurred in sqlmap/CiaDissension.xml.
   3. --- The error occurred while applying a parameter map.
   4. --- Check the QUERY_ALL_DISSENSION_CATEGORY-InlineParameterMap.
   5. --- Check the statement (query failed).
   6. --- Cause: java.sql.SQLException: OALL8 處於不一致狀態
   7.     at com.alibaba.ibatis.BasicIBatisDao.query(BasicIBatisDao.java:315)
   8.     at com.alibaba.china.rcc.riskdc.dao.DissensionCategoryDAO.getAll(DissensionCategoryDAO.java:40)
   9.     at com.alibaba.china.rcc.riskdc.service.impl.DissensionServiceImpl.getCategoryMap(DissensionServiceImpl.java:495)
10.     at com.alibaba.china.rcc.riskdc.service.impl.DissensionServiceImpl.getCategory(DissensionServiceImpl.java:188)
11.     at com.alibaba.china.rcc.riskdc.web.action.DissensionAction.getCategory(DissensionAction.java:263)
12.     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
13.     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
14.     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
15.     at java.lang.reflect.Method.invoke(Method.java:597)
16.     at com.alibaba.webx.action.invoker.AbstractModuleMethodInvoker.executeNoArgMethod(AbstractModuleMethodInvoker.java:401)
17.     ... 33 more

   Caused by: com.alibaba.generalorm.dao.DataAccessException: Data query error!
--- The error occurred in sqlmap/CiaDissension.xml.
--- The error occurred while applying a parameter map.
--- Check the QUERY_ALL_DISSENSION_CATEGORY-InlineParameterMap.
--- Check the statement (query failed).
--- Cause: java.sql.SQLException: OALL8 處於不一致狀態
at com.alibaba.ibatis.BasicIBatisDao.query(BasicIBatisDao.java:315)
at com.alibaba.china.rcc.riskdc.dao.DissensionCategoryDAO.getAll(DissensionCategoryDAO.java:40)
at com.alibaba.china.rcc.riskdc.service.impl.DissensionServiceImpl.getCategoryMap(DissensionServiceImpl.java:495)
at com.alibaba.china.rcc.riskdc.service.impl.DissensionServiceImpl.getCategory(DissensionServiceImpl.java:188)
at com.alibaba.china.rcc.riskdc.web.action.DissensionAction.getCategory(DissensionAction.java:263)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.alibaba.webx.action.invoker.AbstractModuleMethodInvoker.executeNoArgMethod(AbstractModuleMethodInvoker.java:401)
... 33 more

Java程式碼

   1.    Caused by: com.alibaba.generalorm.dao.DataAccessException: Data query error!
   2. --- The error occurred in sqlmap/CiaDissension.xml.
   3. --- The error occurred while applying a parameter map.
   4. --- Check the QUERY_ALL_DISSENSION_BUSINESS-InlineParameterMap.
   5. --- Check the statement (query failed).
   6. --- Cause: java.sql.SQLException: 違反協議
   7.     at com.alibaba.ibatis.BasicIBatisDao.query(BasicIBatisDao.java:315)
   8.     at com.alibaba.china.rcc.riskdc.dao.DissensionBusinessDAO.getAll(DissensionBusinessDAO.java:19)
   9.     at com.alibaba.china.rcc.riskdc.service.impl.DissensionServiceImpl.getBusiness(DissensionServiceImpl.java:178)
10.     at com.alibaba.china.rcc.riskdc.web.action.DissensionAction.getBusiness(DissensionAction.java:249)
11.     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
12.     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
13.     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
14.     at java.lang.reflect.Method.invoke(Method.java:597)
15.     at com.alibaba.webx.action.invoker.AbstractModuleMethodInvoker.executeNoArgMethod(AbstractModuleMethodInvoker.java:401)
16.     ... 33 more

   Caused by: com.alibaba.generalorm.dao.DataAccessException: Data query error!
--- The error occurred in sqlmap/CiaDissension.xml.
--- The error occurred while applying a parameter map.
--- Check the QUERY_ALL_DISSENSION_BUSINESS-InlineParameterMap.
--- Check the statement (query failed).
--- Cause: java.sql.SQLException: 違反協議
at com.alibaba.ibatis.BasicIBatisDao.query(BasicIBatisDao.java:315)
at com.alibaba.china.rcc.riskdc.dao.DissensionBusinessDAO.getAll(DissensionBusinessDAO.java:19)
at com.alibaba.china.rcc.riskdc.service.impl.DissensionServiceImpl.getBusiness(DissensionServiceImpl.java:178)
at com.alibaba.china.rcc.riskdc.web.action.DissensionAction.getBusiness(DissensionAction.java:249)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.alibaba.webx.action.invoker.AbstractModuleMethodInvoker.executeNoArgMethod(AbstractModuleMethodInvoker.java:401)
... 33 more

為什麼會出現違反協議的問題？馬上google一下，有些人說是因為資料庫的欄位型別與java中使用的型別不一致導致，但檢視了ibtais的 map檔案，老的應用程式碼根本還沒有使用新的的欄位！後來找pla共同排查，也沒有發現應用程式哪裡會出現問題，便打電話給DBA讓他查下資料庫，DBA 諮詢了一位資格較老的DBA，他說以前也出現過這種情況，只要將應用重啟下，就好了。馬上重啟，果然問題解決了，違反協議的錯誤沒有再報。

查詢原因：
在做升級前，我自己在開發環境也做過模擬，並沒有出現如果應用不重啟，資料庫變更而報“違反協議”的錯誤。而我看了下發布環境與開發環境差異，唯一的差異是開發環境沒有采用jboss+jndi的方式獲取資料來源，而採用了tomcat+c3p0的方式獲取資料來源。

於是我開始實驗。
Tomcat+C3P0啟動方式:
1.準備好更改資料庫指令碼。
2.在開發環境用tomcat啟動應用，並訪問到涉及表結構變更的頁面。
3.執行資料庫指令碼，確保表結構發生了變更。
4.重新整理在步驟2的頁面，檢視後臺輸出和前臺頁面輸出。
5.一切正常，沒有丟擲違反協議或處於不一致狀態的錯誤日誌。
JBoss4.0.5+JNDI啟動方式
1.準備好更改資料庫指令碼。
2.在開發環境用jboss啟動應用，並訪問到涉及表結構變更的頁面。
3.執行資料庫指令碼，確保表結構發生了變更。
4.重新整理在步驟2的頁面，檢視後臺輸出和前臺頁面輸出。
5.出現了違反協議和處於不一致狀態的問題。

總結：

由此可以看出，出現這個問題與ibatis沒有關係，而與資料來源的獲取方式有關，一種是透過Spring+c3p0直接注入DataSource;一種是在oracle-ds.xml檔案中配置，然後在spring中透過jndi的方式進行查詢，獲取資料來源。第二種在資料庫變更的情況下，就必須進行應用重啟，否則就會丟擲違反協議或處於不一致的狀態。

但根本原因到底是什麼呢？我還在尋找。
===================================================
諮詢了大少，並不是因為資料來源配置模式沒有關係，用c3p0或者jndi等，而是與資料來源的配置方式有關：

在oracle-ds的配置如下：
Java程式碼

   1.
   2.      rccBopsDataSource
   3.      false
   4.      jdbc:oracle:thin:@xx.xx.xx.xx:1521:xx
   5.      true
   6.      50
   7.      GBK
   8.      ISO-8859-1
   9.      com.alibaba.china.jdbc.SimpleDriver
10.      1
11.      14
12.      20
13.
14.          Oracle9i
15.
16.      15
17.      org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter
18.      xx
19.      xx
20.

rccBopsDataSource

false

jdbc:oracle:thin:@xx.xx.xx.xx:1521:xx

true

50

GBK

ISO-8859-1

com.alibaba.china.jdbc.SimpleDriver

1

14

20

Oracle9i

15

org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter

xx

其中prepared-statement-cache-size引數解釋為：

- the number of prepared statements per connection to be kept open and reused in subsequent requests. They are stored in a LRU cache. The default is 0 (zero), meaning no cache.
為每個開啟的資料庫連線快取了一定數量的prepared statement.他們是存在LRU cache中，如果設值為0,那麼將不緩衝。這裡我們設值了每個連線快取20條prepared statment。

而在c3p0的配置中：
Xml程式碼

   1.    2. class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
   3.
   4.     com.mchange.v2.c3p0.DataSources.pooledDataSource
   5.
   6.
   7.
   8.
   9.
10.             1
11.             1
12.             1
13.             5
14.             1800
15.             1000
16.             <!-- 自動收縮連線用的,單位秒 --&gt
17.             <!-- 自動重連需要的三個引數 --&gt
18.             30
19.             1000
20.             false
21.             <!-- 獲取一個connection需要的時間，單位毫秒 --&gt
22.             5000
23.
24.
25.
26. lt;/bean>

   class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">

com.mchange.v2.c3p0.DataSources.pooledDataSource

1
1
1
5
1800
1000
<!-- 自動收縮連線用的,單位秒 --&gt
<!-- 自動重連需要的三個引數 --&gt
30
1000
false
<!-- 獲取一個connection需要的時間，單位毫秒 --&gt
5000

上網查了下，影響到preparedStatment cache的引數有兩個：maxStatements和maxStatementsPerConnection 如果maxStatements與maxStatementsPerConnection均為0，則快取被關閉，預設為0。

繼續實驗：

1、將c3p0配置增加maxStatements和maxStatementsPerConnection並都設值20。
修改資料庫表結構，重新整理訪問頁面。
後臺丟擲違反協議和處於不一致狀態的錯誤提示。

2.將oracle-ds.xml檔案配置更改prepared-statement-cache-size為0。
修改資料庫表結構，重新整理訪問頁面。
後臺沒有丟擲違反協議和處於不一致狀態的錯誤提示。

附參考文章：

1. 講解jboss中關於datasource的引數
2. http://msq.iteye.com/blog/60387   講解c3p0的詳細引數
3. http://13594135.iteye.com/blog/904913

java.sql.SQLException: OALL8 處於不一致狀態

相關文章