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)內(nèi)容劉世偉幾個名詞解釋：數(shù)據(jù)庫連接池：眾所周周知，建立數(shù)據(jù)庫連接是一個個昂貴的操作，每次次都得花費約0.05s1s的的時間，消耗一定的內(nèi)存資源（Oracle 9i的一個空閑連接約需需25MB內(nèi)存存，非空閑連接約約需幾十MB左右內(nèi)存），而且一旦到達達臨界點，系統(tǒng)會會陷入資源管理的的惡性循環(huán)：越來越慢。數(shù)據(jù)庫連接池的的基本思想就是為為數(shù)據(jù)庫連接建立立一個“緩沖池”。

2、預(yù)先在緩沖池池中放入一定數(shù)量量的連接備用，減少使用時時才創(chuàng)建、銷毀的消耗。當需要建立數(shù)據(jù)據(jù)庫連接時，只需需從“緩沖池”中中取出一個，使用用完畢之后再放回回去。使用連接池池后，數(shù)據(jù)庫服務(wù)務(wù)器減少了它并不不擅長的連接管理理工作，通過池連接的快速復(fù)用，可以為客戶戶端提供更大的并并發(fā)量，內(nèi)存消耗耗也在可控范圍內(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ù)。真實連接：客戶端程序序直接和數(shù)據(jù)庫建立的Connection，使用完畢需要及時、安全的關(guān)閉，否

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

4、ache的開源池mons.dbcp.BasicDataSource，應(yīng)用程序獲取的是apache連接池的代理連接（connectionProxy），非真實連接。單連接數(shù)據(jù)源，命名方方式為“xxxDataSourceNoPool”，BSS采用了Spring框架的org.springframework.jdbc.datasource.DriverManagerDataSource，程序獲取的是真實的數(shù)據(jù)庫連接。二、BSS系統(tǒng)中對數(shù)數(shù)據(jù)源的使用Hibernate的的SessionFactory，使用的是連接池數(shù)據(jù)源，在配置文件中一般命名為“xxxSessionFactory”，而且Hibernate

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

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

7、接是連接池的連連接代理（重載了了真實連接的close方方法），需要從代代理連接中再次獲獲取真實連接，見見下面的a段落；如果返回的是單單連接的數(shù)據(jù)源，則則返回的是真實連連接。這2種連接接都需要顯式的close關(guān)關(guān)閉，前者表示把連接還還回連接池繼續(xù)使使用，后者表示真正關(guān)閉連接，釋釋放數(shù)據(jù)庫內(nèi)存。對JdbcTemplate中中返回代理連接的的情況，由于是連連接代理，對Oracle的的Blob和Clob大大數(shù)據(jù)對象，在CLOB.createTemporary(conn, true, CLOB.DURATION_SESSION)的時候，會拋ClassCastException，此時需要獲取真實的物理連接

8、，方法如下：設(shè)置DataSource中中連接池的accessToUnderlyingConnectionAllowed屬性的值為true，表示允許從連接代理中獲取物理連接；對apache的BasicDataSource，可通過mons.dbcp.DelegatingConnection的getDelegate()方法獲取真實連接。注意，通過連接池代理理連接而獲取的真真實連接一定不能直接關(guān)閉閉，否則連接池就就沒有意義了，最好把這種情況況下的獲取物理連接創(chuàng)建Clob用用方法屏蔽掉，防止被誤誤關(guān)閉。代碼掃描后發(fā)現(xiàn)系統(tǒng)中中普遍存在的問題題：1、對打開的數(shù)據(jù)庫資資源conn、ps、rs，主動寫了了clo

9、se語句句，但是沒有寫在在finally語語句塊里面，一旦旦發(fā)生異常，那么么close語句句就會被旁路，導(dǎo)導(dǎo)致資源得不到釋釋放。2、沒有主動寫close語語句，當然這個是是存在一些爭議的的，請看以下解釋釋： a、如果不使使用連接池機制,關(guān)閉connection,會自動關(guān)閉resultset和和statement的的，程序中可以不不顯示關(guān)閉； b、如果使用用連接池,所謂謂的關(guān)閉connection,其實是將連接返返回給了連接池,連連接對象依然存在在,實際上不是是物理關(guān)閉，因此此，必須顯示的關(guān)閉resultset和和statement，否否則連接池中連接接上的rs和ps會會越來越多。3、單獨寫了c

10、lose的的語句塊，到?jīng)]什什么問題，看著不不舒服罷了。附件是代碼中問題的位位置，請詳看。建議：我們系統(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(rs!=null)

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

12、ate的的sessionJdbcTemplate通過session或或jdbcTemplate獲取的Connection，一般直接執(zhí)行sql語句和存儲過程存在的問題：1、事務(wù)回滾規(guī)則只有DAOException（部部分），缺BssException 現(xiàn)在BMO中規(guī)范拋出BssException，一旦BMO方法中出現(xiàn)異常，現(xiàn)在的配置是事務(wù)不回滾的，導(dǎo)致前后數(shù)據(jù)不完整。 建議，spring事務(wù)配置里面加入強制回滾模式匹配： -mon.BssException，如下： PROPAGATION_REQUIRED,-mon.DAOException,-mon.BssException EJB事務(wù)回滾規(guī)則

13、： 1、如果bean拋出RuntimeException，容器會自動回滾事務(wù)，并且在外面包裝一個RemoteException拋出。 2、如果bean拋出其他的異常，容器不會做任何處理，除非強制定義。2、事務(wù)攔截粒度比較粗粗，定義在類級別別而不是方法級別別 事務(wù)攔截器的的配置在bean的的名稱上，該bean下下所有的方法都按按照同一種事務(wù)模模式 象readonly的的事務(wù)隔離模式，對對只查詢不修改的的方法，性能提高高比較大，但需要要更改攔截器，定定義在方法級別。 此條條只涉及性能，影影響不是很大，可可酌情。3、EJB和spring的的事務(wù)傳遞問題 如果BMO中spring不不加載事務(wù)，被EJB

14、包包裝后，發(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)調(diào)用幾個dao，dao中分別用hibernate、jdbc和存儲過程完成insert或update操作，事務(wù)是可以完整的，不過需要注意2點：一是存儲過程里面不能能有commit和rollback二是dao調(diào)用存儲過過程后，dao中也不要寫寫commit和rollback，只要close就可以，由事務(wù)控制自動提交，除非捕捉到bssexception，這里要在spring的事務(wù)攔截中配一下bssexception、daoException，這樣就可以控制異常的回滾。遺留問題：采用連接池后，如果數(shù)數(shù)據(jù)庫存儲過程重重新編譯后，連