今天在看hibernate文檔時，在讀到“
如果應用程序需要更新數據，可能read-write緩存比較合適。如果需要可序列化事務隔離級別（serializable transaction isolation level），這種緩存決不能使用。如果在JTA環境中使用這種緩存，你必須指定hibernate.transaction.manager_lookup_class屬性的值，給出得到JTA TransactionManager的策略。在其它環境中，你必須確保在Session.close()或者Session.disconnect()調用前，事務已經結束了。 如果你要在集群環境下使用這一策略，你必須確保底層的緩存實現支持鎖定(locking)。內置的緩存提供器并不支持。
<class name="eg.Cat" .... >
<jcs-cache usage="read-write"/>
....
<set name="kittens" ... >
<jcs-cache usage="read-write"/>
....
</set>
</class> ”時，對“事務隔離級別”不太清楚（沒辦法，對數據庫了解得較少，會不斷地充實自己的，
），于是上網搜了一把，感覺ibm的網站上解釋得比較好。看了后，認為，之所以拒絕在“可序列化事務隔離級別”的情況下使用讀寫緩存，其實還是為了降低數據存取錯誤發生的機率。
現摘抄“事務隔離級別”一文如下：
事務隔離級別
事務隔離級別指定哪些數據對事務中的語句可視。通過定義對同一目標數據源執行的事務之間的可能交互作用，這些級別直接影響并行訪問級別。
數據庫反常
數據庫反常是生成的結果，這些結果從單一事務的作用域中看上去是不正確的，但從所有事務的作用域中看上去卻是正確的。下面描述了不同類型的數據庫反常：
注意：由于 DB2/400 具有鎖定策略，所以它不會總是使應用程序暴露在規定級別的可允許數據庫反常之下。
JDBC 事務隔離級別
在 IBM Developer Kit for Java JDBC API 中共有五個級別的事務隔離。它們按照限制性從低到高的次序列示如下：
- JDBC_TRANSACTION_NONE
- 這是一個特殊的常量，指示 JDBC 驅動程序不支持事務。
- JDBC_TRANSACTION_READ_UNCOMMITTED
- 此級別允許事務查看對數據所作的未提交更改。在此級別，所有數據庫反常都是有可能的。
- JDBC_TRANSACTION_READ_COMMITTED
- 此級別表示在提交事務之前，在該事務中所作的任何更改在該事務之外都不可視。這杜絕了臟讀取的可能性。
- JDBC_TRANSACTION_REPEATABLE_READ
- 此級別表示保持將讀取的行鎖定，從而使另一事務在此事務完成之前不能更改這些行。這將禁止臟讀取和不可重復讀取?；孟笞x取仍是有可能的。
- JDBC_TRANSACTION_SERIALIZABLE
- 在事務期間將表鎖定，從而使其它對表添加值或除去值的事務不能更改 WHERE 條件。這將杜絕所有類型的數據庫反常。
可使用 setTransactionIsolation 方法來更改連接的事務隔離級別。
注意事項
有一種常見的誤解，即認為 JDBC 規范定義了前面提到的五個事務級別。通常認為 TRANSACTION_NONE 值表示在不存在提交控制的情況下運行這一概念。然而，JDBC 規范并沒有以同一方式定義 TRANSACTION_NONE。在 JDBC 規范中，將 TRANSACTION_NONE 定義成這樣的一個級別：在這個級別，驅動程序不支持事務并且不是與 JDBC 相符的驅動程序。在調用 getTransactionIsolation 方法時，從來不會報告 NONE 級別。
由于 JDBC 驅動程序的缺省事務隔離級別是由實現定義的，所以問題稍微有點復雜。本機 JDBC 驅動程序缺省事務隔離級別的缺省事務隔離級別是 NONE。這允許驅動程序使用沒有日志的文件，并且您不需要作任何指定（如指定 QGPL 庫中的文件）。
本機 JDBC 驅動程序允許將 JDBC_TRANSACTION_NONE 傳送給 setTransactionIsolation 方法或指定 none 作為連接屬性。然而，當值為 none 時，getTransactionIsolation 方法總是報告 JDBC_TRANSACTION_READ_UNCOMMITTED。跟蹤正在運行的級別是應用程序的職責（如果應用程序有此需要的話）。
在過去的發行版中，由于系統沒有真正自動提交方式這一概念，所以，如果對自動提交指定 true，則 JDBC 驅動程序將通過把事務隔離級別更改為 none 來進行處理。這在功能上極為相似，但并非在所有方案下都能提供正確的結果?，F在情況已有所不同；數據庫已將自動提交的概念與事務隔離級別的概念分開。因此，在啟用自動提交的情況下在 JDBC_TRANSACTION_SERIALIZABLE 級別運行是完全有效的。唯一無效的方案是在 JDBC_TRANSACTION_NONE 級別運行并且不處于自動提交方式。當系統不是在具有事務隔離級別的情況下運行時，應用程序不能控制提交邊界。
JDBC 規范與 iSeries 平臺之間的事務隔離級別
iSeries 平臺的事務隔離級別具有公共的名稱，這些名稱與 JDBC 規范提供的那些名稱不匹配。下表對 iSeries 平臺使用的那些與 JDBC 規范所使用的名稱不匹配的名稱作了匹配：
| JDBC 級別 * |
iSeries 級別 |
| JDBC_TRANSACTION_NONE |
*NONE 或 *NC |
| JDBC_TRANSACTION_READ_UNCOMMITTED |
*CHG 或 *UR |
| JDBC_TRANSACTION_READ_COMMITTED |
*CS |
| JDBC_TRANSACTION_REPEATABLE_READ |
*ALL 或 *RS |
| JDBC_TRANSACTION_SERIALIZABLE |
*RR |
* 在這個表中，JDBC_TRANSACTION_NONE 值與 iSeries 級別 *NONE 和 *NC 排在一起是為了使您看得更清楚。這并不是直接的從規范到 iSeries 級別的匹配。
原文引自：http://publib.boulder.ibm.com/iseries/v5r2/ic2989/index.htm?info/rzaha/transiso.htm