• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            woaidongmao

            文章均收錄自他人博客,但不喜標題前加-[轉貼],因其丑陋,見諒!~
            隨筆 - 1469, 文章 - 0, 評論 - 661, 引用 - 0
            數據加載中……

            JDBC的數據庫事務

                     事務是工作中的基本邏輯單位。數據庫的主要責任是保存信息,因此它需要向用戶提供保存當前程序狀態的方法。同樣,當事務執行過程中發生錯誤時,需要有一種方法使數據庫忽略當前的狀態,并回到前面保存的程序狀態。這兩種情況在數據庫用語中分別稱為提交事務和回滾事務。為了處理這兩種情況,JDBC API     包括了兩個方法commit()rollback(),分別用于實現事務的提交和回滾。在使用這兩個方法時通常要使用try ... catch語句捕獲數據庫實際運行操作時可能發生的SQLException

                    
            當多個用戶訪問相同的數據時,可能會出現3種問題:
                

            ?  臟讀如果一個應用程序使用了被另一個應用程序修改過的數據,而這個數據處于未提交狀態,這時就會發生臟讀。第二個應用程序隨后會請求回滾被其修改的數據,從而導致第一個事務使用的數據被損壞,即所謂"變臟"
                

            ?  不可重復的讀如果一個事務獲得了數據,而該數據隨后被另一個事務所更改,那么第一個事務再次讀取更改后的數據,就會發生不可重復的讀。
                

            ?  虛讀如果一個事務通過某種查詢獲取了數據,另一個事務修改了該數據的一部分,那么原來的事務第二次獲取該數據時,就會發生虛讀。

                     
            為了解決這些由于多個用戶請求相同數據而引起的問題,事務之間必須用鎖相互隔開。多數主流的數據庫支持不同類型的鎖;因此,JDBC API支持不同類型的事務,它們由 Connection對象的setTransactionLevel方法指定。在JDBC API中可以獲得下列事務級別:
                

            ?  TRANSACTION_NONE 說明不支持事務。
                

            ?  TRANSACTION_READ_UNCOMMITTED 說明一個事務在提交前其變化對于其他事務來說是可見的。這樣臟讀、不可重復的讀和虛讀都是允許的。
                

            ?  TRANSACTION_READ_COMMITTED 說明讀取未提交的數據是不允許的。這個級別仍然允許不可重復的讀和虛讀產生。
                

            ?  TRANSACTION_REPEATABLE_READ 說明事務保證能夠再次讀取相同的數據而不會失敗,但虛讀仍然會出現。
                

            ?  TRANSACTION_SERIALIZABLE 是最高的事務級別,它防止臟讀、不可重復的讀和虛讀。 

                    
            運行在TRANSACTION_SERIALIZABLE模式下的事務可以保證最高程度的數據完整性,但事務保護的級別越高,性能損失就越大。

                    
            假設我們現在有一個Connection對象con,那么設置事務級別的方法如下: 
                     con.setTransactionLevel(TRANSACTION_SERIALIZABLE) ;

                    
            你也可以使用getTransactionLevel()方法來獲取當前事務的級別:
                      con.getTransactionLevel();

                    
            在默認情況下,JDBC驅動程序運行在"自動提交"模式下,即發送到數據庫的所有命令運行在它們自己的事務中。這樣做雖然方便,但付出的代價是程序運行時的開銷比較大。我們可以利用批處理操作減小這種開銷,因為在一次批處理操作中可以執行多個數據庫更新操作。但批處理操作要求事務不能處于自動提交模式下。為此,我們首先要禁用自動提交模式。

                     executeBatch()方法返回一個更新計數的數組,每個值對應于批處理操作中的一個命令。批處理操作可能會拋出一個類型為BatchUpdateException的異常,這個異常表明批處理操作中至少有一條命令失敗了。(T111)

             

            posted on 2009-08-11 13:06 肥仔 閱讀(255) 評論(0)  編輯 收藏 引用 所屬分類: Web-后臺

            国产精品久久久久乳精品爆| 久久无码专区国产精品发布| 国产欧美一区二区久久| 亚洲精品乱码久久久久久蜜桃不卡 | 久久久久无码精品| 久久国产精品一区| 亚洲精品视频久久久| 久久人人爽人人爽人人片AV麻烦| 少妇久久久久久久久久| 99久久夜色精品国产网站| 久久91这里精品国产2020| 思思久久99热只有频精品66| 国产美女久久精品香蕉69| 伊人久久大香线蕉无码麻豆| 好久久免费视频高清| 久久亚洲国产成人影院网站| 无码人妻久久一区二区三区免费丨 | 久久无码一区二区三区少妇 | 亚洲狠狠综合久久| 久久精品国产亚洲av麻豆图片 | 久久久久亚洲AV综合波多野结衣 | 久久人人妻人人爽人人爽| 久久99久久无码毛片一区二区| 日韩精品久久无码中文字幕| 2022年国产精品久久久久| 亚洲精品tv久久久久| 97精品伊人久久久大香线蕉| 精品人妻久久久久久888| 伊人精品久久久久7777| 久久人妻少妇嫩草AV无码蜜桃| 久久国产精品-久久精品| 婷婷久久香蕉五月综合加勒比| 亚洲国产成人久久综合野外| 久久久久亚洲精品中文字幕| 精品久久久久久国产91| 91精品国产高清91久久久久久| 久久久亚洲欧洲日产国码aⅴ| 囯产精品久久久久久久久蜜桃 | 精品国产乱码久久久久久郑州公司 | 亚洲精品乱码久久久久久久久久久久| 久久伊人精品青青草原日本|