JDBC2.0擴展API(3)

2019-11-18 13:59:50

字體：大中小

來源：轉載

供稿：網友

　　二、Connection pooling（連接池）：
　　連接池是這么一種機制，當應用程序關閉一個Connection的時候，這個連接被回收，而不是被destroy，因為建立一個連接是一個很費資源的操作。假如能把回收的連接重新利用，會減少新創建連接的數目，顯著的提高運行的性能。
　　假設應用程序需要建立到一個名字為EmpolyeeDB的DataSource的連接。使用連接池得到連接的代碼如下：
　　 Context ctx = new InitialContext(); DataSource ds = (DataSource)ctx.lookup("jdbc/EmployeeDB");Connection con = ds.getConnection("myPassWord", "myUserName");除了邏輯名字以外，我們發現其代碼和上面舉的例子的代碼是一樣的。邏輯名字不同，就可以連接到不同的數據庫。DataSource對象的getConnection方法返回的Connection是否是一個連接池中的連接完全取決于DataSource對象的實現方法。假如DataSource對象實現與一個支持連接池的中間層的服務器一起工作，DataSource對象就會自動的返回連接池中的連接，這個連接也是可以重復利用的。
　　是否使用連接池獲得一個連接，在應用程序的代碼上是看不出不同的。在使用這個Connection連接上也沒有什么不一樣的地方，唯一的不同是在java的finally語句塊中來關閉一個連接。在finally中關閉連接是一個好的編程習慣。這樣，即使方法拋出異常，Connection也會被關閉并回收到連接池中去。代碼應該如下所示：
　　try{…
　　}catch（）{…
　　}finally{ if（con!=null）con.close();}
　　三、分布式事務：
　　獲得一個用來支持分布式事務的連接與獲得連接池中的連接是很相似的。同樣，不同之處在于DataSource的實現上的不同，而不是在應用程序中獲得連接的方式上有什么不同。假設DataSource的實現可以與支持分布式事務中間層服務器一起工作，得到連接的代碼還是如下所示：
　　 Context ctx = new InitialContext(); DataSource ds = (DataSource)ctx.lookup("jdbc/EmployeeDB"); Connection con = ds.getConnection("myPassword", "myUserName");由于性能上的原因，假如一個DataSource能夠支持分布式的事務，它同樣也可以支持連接池治理。
　　從應用程序設計者的觀點來看。是否支持分布式的事務的連接對它來說沒什么不同，唯一的不同是在事務的邊界上（開始一個事務的地方和結束一個事務的地方），開始一個事務或者結束一個事務都是由事務服務器來控制的。應用程序不應該做任何可能妨礙服務的事情。應用程序不能夠直接調用事務提交commit或者回滾rollback操作，也不能夠使用事務的自動提交模式auto-commit mode（在數據庫操作完成的時候自動的調用commit或者rollback）。

上一篇：JDBC2.0擴展API(2)

下一篇：JDBC2.0擴展API(4)