BSS_QC_數(shù)據(jù)庫連接和事務(wù)管理專題

1、BSS系統(tǒng)中數(shù)據(jù)庫連接的安全使用和事務(wù)問題匯總V1.0.1修改日期原因修改人2007-09-30根據(jù)zhaoxin的意見，修改了Hibernate的session連接管理劉世偉2007-11-8根據(jù)調(diào)優(yōu)組當前的工作，補充了一些內(nèi)容劉世偉幾個名詞解釋：1、 數(shù)據(jù)庫連接池：眾所周知，建立數(shù)據(jù)庫連接是一個昂貴的操作，每次都得花費約0.05s1s的時間，消耗一定的內(nèi)存資源（Oracle 9i的一個空閑連接約需25MB內(nèi)存，非空閑連接約需幾十MB左右內(nèi)存），而且一旦到達臨界點，系統(tǒng)會陷入資源管理的惡性循環(huán)：越來越慢。數(shù)據(jù)庫連接池的基本思想就是為數(shù)據(jù)庫連接建立一個“緩沖池”。預先在緩沖池中放入一定數(shù)量的連

2、接備用，減少使用時才創(chuàng)建、銷毀的消耗。當需要建立數(shù)據(jù)庫連接時，只需從“緩沖池”中取出一個，使用完畢之后再放回去。使用連接池后，數(shù)據(jù)庫服務(wù)器減少了它并不擅長的連接管理工作，通過池連接的快速復用，可以為客戶端提供更大的并發(fā)量，內(nèi)存消耗也在可控范圍內(nèi)波動。我們可以通過設(shè)定連接池最大連接數(shù)來防止系統(tǒng)無盡的與數(shù)據(jù)庫連接，控制數(shù)據(jù)庫的壓力。我們也可以通過連接池的管理機制監(jiān)控數(shù)據(jù)庫連接的數(shù)量使用情況，為系統(tǒng)開發(fā)測試及性能調(diào)優(yōu)提供依據(jù)。2、 真實連接：客戶端程序直接和數(shù)據(jù)庫建立的Connection，使用完畢需要及時、安全的關(guān)閉，否則會導致數(shù)據(jù)庫內(nèi)存資源泄漏、服務(wù)器宕機3、 代理連接：客戶端程序從連接池獲取的

3、Connection，它實際上是封裝了真實連接，提供和真實連接相同的功能，使用完畢也需要及時、安全的關(guān)閉，否則連接池中的連接得不到釋放，會導致連接池中可用的空閑連接越來越少。當然，由于存在連接池的控制，數(shù)據(jù)庫不會因此而宕機。一、BSS數(shù)據(jù)庫連接管理現(xiàn)狀：BSS系統(tǒng)中對數(shù)據(jù)庫連接的管理，是統(tǒng)一通過數(shù)據(jù)源（DataSource）管理的，存在連接池和單連接兩種方式的數(shù)據(jù)源（詳情參考modelxxx.jar中的xxxDatabase.xml文件）1、 連接池數(shù)據(jù)源，命名方式為“xxxDataSource”，BSS采用了apache的開源池mons.dbcp.BasicDataSource，應(yīng)用程序獲取

4、的是apache連接池的代理連接（connectionProxy），非真實連接。2、 單連接數(shù)據(jù)源，命名方式為“xxxDataSourceNoPool”，BSS采用了Spring框架的org.springframework.jdbc.datasource.DriverManagerDataSource，程序獲取的是真實的數(shù)據(jù)庫連接。二、BSS系統(tǒng)中對數(shù)據(jù)源的使用1、 Hibernate的SessionFactory，使用的是連接池數(shù)據(jù)源，在配置文件中一般命名為“xxxSessionFactory”，而且Hibernate本身包含一個簡單的連接池hibernate.connection，但性能和

5、功能不如apache的。2、 Spring的JdbcTemplate,根據(jù)其使用數(shù)據(jù)源是否為連接池，命名方式也不同，配置文件中對使用連接池數(shù)據(jù)源的命名為“xxxJDBC”，使用單連接數(shù)據(jù)源的命名為“xxxJDBCNoPool”三、應(yīng)用程序中對連接的使用BSS程序中使用Hibernate的session和JdbcTemplate提供的通用方法一般是夠用的，但某些場景下如執(zhí)行oracle特性的SQL語句或存儲過程，需要獲取真實數(shù)據(jù)庫連接，現(xiàn)在主要使用以下幾種方式：1、 Hibernate中，通過getSession().connection()，此時獲取的是連接是根據(jù)其數(shù)據(jù)源決定的，如果通過連接池

6、中獲取，則是代理連接，否則是真實數(shù)據(jù)庫連接，但注意，無論如何都不能用conn.close()語句顯示關(guān)閉的；這時候的conn其實是被session管理了，Hibernate會在Session的事務(wù)提交或回滾的時候，自動把連接放回池中，如果我們主動關(guān)了，會拋異常。2、 JdbcTemplate中，通過jdbc.getDataSource().getConnection()，此時獲取的連接是根據(jù)其數(shù)據(jù)源決定的，如果jdbc.getDataSource()返回的是連接池數(shù)據(jù)源，則連接是連接池的連接代理（重載了真實連接的close方法），需要從代理連接中再次獲取真實連接，見下面的a段落；如果返回的是單

7、連接的數(shù)據(jù)源，則返回的是真實連接。這2種連接都需要顯式的close關(guān)閉，前者表示把連接還回連接池繼續(xù)使用，后者表示真正關(guān)閉連接，釋放數(shù)據(jù)庫內(nèi)存。a) 對JdbcTemplate中返回代理連接的情況，由于是連接代理，對Oracle的Blob和Clob大數(shù)據(jù)對象，在CLOB.createTemporary(conn, true, CLOB.DURATION_SESSION)的時候，會拋ClassCastException，此時需要獲取真實的物理連接，方法如下：i. 設(shè)置DataSource中連接池的accessToUnderlyingConnectionAllowed屬性的值為true，表示允許從

8、連接代理中獲取物理連接；ii. 對apache的BasicDataSource，可通過mons.dbcp.DelegatingConnection的getDelegate()方法獲取真實連接。iii. 注意，通過連接池代理連接而獲取的真實連接一定不能直接關(guān)閉，否則連接池就沒有意義了，最好把這種情況下的獲取物理連接創(chuàng)建Clob用方法屏蔽掉，防止被誤關(guān)閉。代碼掃描后發(fā)現(xiàn)系統(tǒng)中普遍存在的問題：1、對打開的數(shù)據(jù)庫資源conn、ps、rs，主動寫了close語句，但是沒有寫在finally語句塊里面，一旦發(fā)生異常，那么close語句就會被旁路，導致資源得不到釋放。2、沒有主動寫close語句，當然這個是

9、存在一些爭議的，請看以下解釋：    a、如果不使用連接池機制, 關(guān)閉connection, 會自動關(guān)閉resultset和statement的，程序中可以不顯示關(guān)閉；    b、如果使用連接池, 所謂的關(guān)閉connection, 其實是將連接返回給了連接池,連接對象依然存在, 實際上不是物理關(guān)閉，因此，必須顯示的關(guān)閉resultset和statement，否則連接池中連接上的rs和ps會越來越多。3、單獨寫了close的語句塊，到?jīng)]什么問題，看著不舒服罷了。附件是代碼中問題的位置，請

10、詳看。建議：我們系統(tǒng)有使用連接池和單獨創(chuàng)建連接的，所以保險起見，resultset和statment（PreparedStatement、CallableStatement）一定在finally語句里面主動保持先后次序close掉，在此貼一下示例程序。Connection con = null;PreparedStatement ps = null;ResultSet rs = null;try .catch （SQLException ex）.finally    try         if

11、(rs!=null)            rs.close();        catch (SQLException ex)         /錯誤處理        try         if(ps!=null) 

12、;           ps.close();        catch (SQLException ex)         /錯誤處理        try        if(con!=null) /注意：Hibernate中

13、得到的conn不能關(guān)閉。            con.close();        catch (SQLException ex)         /錯誤處理     數(shù)據(jù)庫事務(wù)管理現(xiàn)狀：BSS中采用了Spring的聲明式事務(wù)管理，在配置文件中通過對象或方法的名稱通配事務(wù)的加載與否。由于存在以上的數(shù)據(jù)庫連接管理方式

14、，所以對數(shù)據(jù)庫的事務(wù)管理也是存在多種方式：1、 Hibernate的session2、 JdbcTemplate3、 通過session或jdbcTemplate獲取的Connection，一般直接執(zhí)行sql語句和存儲過程存在的問題：1、事務(wù)回滾規(guī)則只有DAOException（部分），缺BssException        現(xiàn)在BMO中規(guī)范拋出BssException，一旦BMO方法中出現(xiàn)異常，現(xiàn)在的配置是事務(wù)不回滾的，導致前后數(shù)據(jù)不完整。       

15、; 建議，spring事務(wù)配置里面加入強制回滾模式匹配： -mon.BssException，如下：                <property name="transactionAttribute">                 

16、60; <value>PROPAGATION_REQUIRED,-mon.DAOException,-mon.BssException</value>                </property>  EJB事務(wù)回滾規(guī)則：    1、如果bean拋出RuntimeException，容器會自動回滾事務(wù)，并且在外面包裝一個RemoteException拋出。 

17、;   2、如果bean拋出其他的異常，容器不會做任何處理，除非強制定義。 2、事務(wù)攔截粒度比較粗，定義在類級別而不是方法級別        事務(wù)攔截器的配置在bean的名稱上，該bean下所有的方法都按照同一種事務(wù)模式        象readonly的事務(wù)隔離模式，對只查詢不修改的方法，性能提高比較大，但需要更改攔截器，定義在方法級別。        此

18、條只涉及性能，影響不是很大，可酌情。3、EJB和spring的事務(wù)傳遞問題        如果BMO中spring不加載事務(wù)，被EJB包裝后，發(fā)現(xiàn)EJB的事務(wù)不能傳遞給spring，EJB事務(wù)回滾了，但是spring管理bean的事務(wù)仍舊提交了，原因待詳查，初步分析是ejb容器和spring容器事務(wù)不能透傳，按照EJB規(guī)范，CMT（容器管理的事務(wù)）內(nèi)部是不能有嵌套事務(wù)的。當前為規(guī)避此種情況，建議所有的BMO，如果需要事務(wù)的，名稱一律按照規(guī)范以“Manager”“DAO”結(jié)尾。調(diào)優(yōu)組正在組織力量集中解決這個問題，初步思路是啟用EJB BMT(Bean 管理事務(wù))，使用websphere的事務(wù)管理和連接池存儲過程和Java事務(wù)的嵌套問題：在一個bmo中同時調(diào)用幾個dao，dao中分別用hibernate、jdbc和存儲過程完成insert或update操作，事務(wù)是可以完整的，不過需要注意2點：一是存儲過程里面不能有commit和rollback二是dao調(diào)用存儲過程后，dao中也不要寫commit和rollback，只要close就可以，由事務(wù)控制自動提交，除非捕捉到bssexception