在標準sql規范中，定義了4個事務隔離級別，不同的隔離級別對事務的處理不同:
◆未授權讀取（read uncommitted）：允許臟讀取，但不允許更新丟失。如果一個事務已經開始寫數據，則另外一個數據則不允許同時進行寫操作，但允許其他事務讀此行數據。該隔離級別可以通過"排他寫鎖"實現。
◆授權讀取（read committed）：允許不可重復讀取，但不允許臟讀取。這可以通過"瞬間共享讀鎖"和"排他寫鎖"實現。讀取數據的事務允許其他事務繼續訪問該行數據，但是未提交的寫事務將會禁止其他事務訪問該行。
◆可重復讀取（repeatable read）：禁止不可重復讀取和臟讀取，但是有時可能出現幻影數據。這可以通過"共享讀鎖"和"排他寫鎖"實現。讀取數據的事務將會禁止寫事務（但允許讀事務），寫事務則禁止任何其他事務。
◆序列化（serializable）：提供嚴格的事務隔離。它要求事務序列化執行，事務只能一個接著一個地執行，但不能并發執行。如果僅僅通過"行級鎖"是無法實現事務序列化的，必須通過其他機制保證新插入的數據不會被剛執行查詢操作的事務訪問到。
      隔離級別越高，越能保證數據的完整性和一致性，但是對并發性能的影響也越大。對于多數應用程序，可以優先考慮把數據庫系統的隔離級別設為read committed，它能夠避免臟讀取，而且具有較好的并發性能。盡管它會導致不可重復讀、虛讀和第二類丟失更新這些并發問題，在可能出現這類問題的個別場合，可以由應用程序采用悲觀鎖或樂觀鎖來控制。
      通過前面的介紹已經知道，通過選用不同的隔離等級就可以在不同程度上避免前面所提及的在事務處理中所面臨的各種問題。所以，數據庫隔離級別的選取就顯得尤為重要，在選取數據庫的隔離級別時，應該注意以下幾個處理的原則：
首先，必須排除"未授權讀取"，因為在多個事務之間使用它將會是非常危險的。事務的回滾操作或失敗將會影響到其他并發事務。第一個事務的回滾將會完全將其他事務的操作清除，甚至使數據庫處在一個不一致的狀態。很可能一個已回滾為結束的事務對數據的修改最后卻修改提交了，因為"未授權讀取"允許其他事務讀取數據，最后整個錯誤狀態在其他事務之間傳播開來。
其次，絕大部分應用都無須使用"序列化"隔離（一般來說，讀取幻影數據并不是一個問題），此隔離級別也難以測量。目前使用序列化隔離的應用中，一般都使用悲觀鎖，這樣強行使所有事務都序列化執行。
剩下的也就是在"授權讀取"和"可重復讀取"之間選擇了。我們先考慮可重復讀取。如果所有的數據訪問都是在統一的原子數據庫事務中，此隔離級別將消除一個事務在另外一個并發事務過程中覆蓋數據的可能性（第二個事務更新丟失問題）。這是一個非常重要的問題，但是使用可重復讀取并不是解決問題的唯一途徑。
     假設使用了"版本數據"，hibernate會自動使用版本數據。hibernate的一級session緩存和版本數據已經為你提供了"可重復讀取隔離"絕大部分的特性。特別是，版本數據可以防止二次更新丟失的問題，一級session緩存可以保證持久載入數據的狀態與其他事務對數據的修改隔離開來，因此如果使用對所有的數據庫事務采用授權讀取隔離和版本數據是行得通的。
     "可重復讀取"為數據庫查詢提供了更好的效率（僅對那些長時間的數據庫事務），但是由于幻影讀取依然存在，因此沒必要使用它（對于web應用來說，一般也很少在一個數據庫事務中對同一個表查詢兩次）。
也可以同時考慮選擇使用hibernate的二級緩存，它可以如同底層的數據庫事務一樣提供相同的事務隔離，但是它可能弱化隔離。假如在二級緩存大量使用緩存并發策略，它并不提供重復讀取語義（例如，后面章節中將要討論的讀寫，特別是非嚴格讀寫），很容易可以選擇默認的隔離級別：因為無論如何都無法實現"可重復讀取"，因此就更沒有必要拖慢數據庫了。另一方面，可能對關鍵類不采用二級緩存，或者采用一個完全的事務緩存，提供"可重復讀取隔離"。那么在業務中需要使用到"可重復讀取"嗎？如果你喜歡，當然可以那樣做，但更多的時候并沒有必要花費這個代價。