如果只提交一個(gè)查詢，有必要用事務(wù)嗎？這個(gè)問題之前已經(jīng)討論過(guò)
http://forum.javaeye.com/viewtopic.php?t=1603
但是并沒有得出明確的結(jié)論。先讓我們看看事務(wù)的定義：
引用:
Transactions are described in terms of ACID properties, which are as follows:
n Atomic: all changes to the database made in a transaction are rolled back if any
change fails.
n Consistent: the effects of a transaction take the database from one consistent
state to another consistent state.
n Isolated: the intermediate steps in a transaction are not visible to other users of
the database.
n Durable: when a transaction is completed (committed or rolled back), its effects
persist in the database.
即ACID的定義，從上面看來(lái)，似乎除了isolated之外，和只讀查詢都沒有關(guān)系。那么是否只讀查詢不需要事務(wù)呢？
再看看Oracle對(duì)于只讀事務(wù)的定義：
引用:
Read-Only Transactions
By default, Oracle guarantees statement-level read consistency. The set of data returned by a single query is consistent with respect to a single point in time. However, in some situations, you might also require transaction-level read consistency. This is the ability to run multiple queries within a single transaction, all of which are read-consistent with respect to the same point in time, so that queries in this transaction do not see the effects of intervening committed transactions.
If you want to run a number of queries against multiple tables and if you are not doing any updating, you prefer a read-only transaction. After indicating that your transaction is read-only, you can run as many queries as you like against any table, knowing that the results of each query are consistent with respect to the same point in time.
Oracle默認(rèn)情況下保證了SQL語(yǔ)句級(jí)別的讀一致性，即在該條SQL語(yǔ)句執(zhí)行期間，它只會(huì)看到執(zhí)行前點(diǎn)的數(shù)據(jù)狀態(tài)，而不會(huì)看到執(zhí)行期間數(shù)據(jù)被其他SQL改變的狀態(tài)。
而Oracle的只讀查詢(read-only transaction)則保證了事務(wù)級(jí)別的讀一致性，即在該事務(wù)范圍內(nèi)執(zhí)行的多條SQL都只會(huì)看到執(zhí)行前點(diǎn)的數(shù)據(jù)狀態(tài)，而不會(huì)看到事務(wù)期間的任何被其他SQL改變的狀態(tài)。
因此我們可以得出結(jié)論：
如果你一次執(zhí)行單條查詢語(yǔ)句，則沒有必要啟用事務(wù)支持，數(shù)據(jù)庫(kù)默認(rèn)支持SQL執(zhí)行期間的讀一致性；
如果你一次執(zhí)行多條查詢語(yǔ)句，例如統(tǒng)計(jì)查詢，報(bào)表查詢，在這種場(chǎng)景下，多條查詢SQL必須保證整體的讀一致性，否則，在前條SQL查詢之后，后條SQL查詢之前，數(shù)據(jù)被其他用戶改變，則該次整體的統(tǒng)計(jì)查詢將會(huì)出現(xiàn)讀數(shù)據(jù)不一致的狀態(tài)，此時(shí)，應(yīng)該啟用事務(wù)支持。
只讀事務(wù)與讀寫事務(wù)區(qū)別
對(duì)于只讀查詢，可以指定事務(wù)類型為readonly，即只讀事務(wù)。由于只讀事務(wù)不存在數(shù)據(jù)的修改，因此數(shù)據(jù)庫(kù)將會(huì)為只讀事務(wù)提供一些優(yōu)化手段，例如Oracle對(duì)于只讀事務(wù)，不啟動(dòng)回滾段，不記錄回滾log。
在JDBC中，指定只讀事務(wù)的辦法為：
connection.setReadOnly(true);
在Hibernate中，指定只讀事務(wù)的辦法為：
session.setFlushMode(FlushMode.NEVER);
此時(shí)，Hibernate也會(huì)為只讀事務(wù)提供Session方面的一些優(yōu)化手段
在Spring的Hibernate封裝中，指定只讀事務(wù)的辦法為：
bean配置文件中，prop屬性增加“readOnly”
我在MySQL4.1試驗(yàn)了一下，過(guò)程和結(jié)果如下：
數(shù)據(jù)庫(kù)：MySQL4.1
表類型：InnoDB
Spring：1.1.2
Hibernate：2.1.7
使用Spring的聲明式事務(wù)管理
試驗(yàn)過(guò)程如下：
不設(shè)置查詢方法的事務(wù)類型(即不需要事務(wù))：訪問查詢頁(yè)面，后臺(tái)執(zhí)行Spring的Bean方法，讓Hibernate發(fā)送select語(yǔ)句，然后手工在MySQL里面修改該記錄某字段值，再訪問查詢頁(yè)面，發(fā)現(xiàn)被修改過(guò)的字段值并沒有變化，Hibernate輸出的log顯示，數(shù)據(jù)庫(kù)還是把老的字段值返回，而沒有返回新的字段值。
設(shè)置查詢方法的事務(wù)類型(只讀事務(wù))：訪問查詢頁(yè)面，后臺(tái)執(zhí)行Spring的Bean方法，讓Hibernate發(fā)送select語(yǔ)句，然后手工在MySQL里面修改該記錄某字段值，再訪問查詢頁(yè)面，發(fā)現(xiàn)被修改過(guò)的字段值已經(jīng)變化，Hibernate輸出的log顯示，數(shù)據(jù)庫(kù)返回新的字段值。
這個(gè)試驗(yàn)說(shuō)明，至少在MySQL4.1的InnoDB情況下，不使用只讀事務(wù)的查詢將無(wú)法讀取到數(shù)據(jù)更新值，必須使用只讀事務(wù)來(lái)保證讀記錄的數(shù)據(jù)一致性。這個(gè)結(jié)果非常令我詫異，和我預(yù)期完全兩樣。
我將在Oracle平臺(tái)上試試看會(huì)有什么樣的結(jié)果。
BTW: 如果MySQL的表類型改為MyISAM，那么即使不設(shè)置事務(wù)，也不會(huì)出現(xiàn)讀數(shù)據(jù)不一致的現(xiàn)象。
oracle有兩種方法保證在事務(wù)級(jí)讀數(shù)據(jù)一致性(Transaction-Level Read Consistency)
一是用SET TRANSACTION ISOLATION LEVEL SERIALIZABLE ,
當(dāng)執(zhí)行這條命令后讀數(shù)據(jù)時(shí)會(huì)產(chǎn)生一些重復(fù)copy, 你也可以做數(shù)據(jù)修改, 但在大量數(shù)據(jù)修改的情況下容易造成deadlock或異常, 用commit或rollback將把ISOLATION LEVEL設(shè)回為缺省模式read committed,
二是用SET TRANSCATION READ ONLY
當(dāng)執(zhí)行這條命令時(shí)數(shù)據(jù)庫(kù)會(huì)生成一個(gè)快照的latch, 這個(gè)latch會(huì)耗費(fèi)一些resource, 如果你想進(jìn)行數(shù)據(jù)修改會(huì)導(dǎo)致異常. 用commit或rollback會(huì)把latch釋放掉, 也將把ISOLATION LEVEL設(shè)回為缺省模式read committed,