JDBC 2.0 API 包括兩個package:
1. java.sql 為JDBC 2.0的核心包，其中包括了JDBC 1.0規范中規定的API和新的核心API，這個包包含於Java 2 Standard Edition中.
2. javax.sql 為JDBC 2.0的標准擴展包，相對與JDBC 1.0而言是全新的，這個包包含於Java 2 Enterprise Edition中.
★ 采用了新的方法連接數據庫 DataSource Interface
JDBC 2.0 提供了新的接口DataSource用來實現數據庫連接,可以替代1.0中提供的DriverManager類。好處是:
☆ 增強了代碼的可移植性
☆ 方便了代碼的維護
一個DataSource對象代表一個實際的數據源。這個數據源可以是從關系數據庫到表格形式的文件,完全依賴於它是怎樣實現的.一個數據源對象注冊到JNDI名字服務後,應用程序就可以從JNDI服務器上取得該對象,並使用之和數據源建立連接.
數據源及如何裝入的信息(名字,地址,端口等等)以PropertIEs的形式保存在DataSource對象中.這樣就增強了應用程序的可移植性,因為程序中不需要像使用DriverManager那樣給出硬性的驅動器名字(往往包含了特定廠商的名字). 這種做法還增強了代碼的可維護性,比如數據源移植到另一台服務器上後, 所需要作的就是更新一下相關的property,使用數據源的代碼更不不必改動.
系統管理員或者有相應權限的人實現DataSource對象. DataSource對象的實現需要設置對象的propertIEs並把它注冊到JNDI名字服務器上, 這些活動可能會用特定工具來實現. 系統管理員用一個邏輯名字對應DataSource對象,這個名字可是是任意的. 在下面的例子中DataSource對象的名字是InventoryDB. 依照傳統習慣, DataSource對象的名字包含在jdbc下, 所以這個數據源對象的完整名字是:jdbc/InventoryDB.
實現數據源對象後, 應用程序員就可以使用它來建立和數據源之間的連接了. 下面的代碼片斷演示了通過這種方式獲得連接. 上面兩行使用了JNDI API獲得DataSource對象,第三行代碼使用JDBC API獲得連接:
Context ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("jdbc/InventoryDB"):
Connection conn = ds.getConnection("passWord","username");
DataSource對象中獲得的的Connection對象和用DriverManager.getConnection方法獲得的對象是等同的. 由於DataSource方法的優點, 該方法成為獲得連接的推薦方法. 所有基於JDBC 2.0的驅動器應該會包含DataSource接口的實現以及Javax.sql包.
對普通程序員而言, DataSource對象方法只是一種選擇. 如果要使用連接緩沖池(Connection pooling)或者分布式交換, 則必須使用DataSource對象獲得連接.原因在下文中闡述.
★ Connection Pooling
連接緩沖池是這樣工作的:當一個應用程序關閉一個連接時, 這個連接並不真正釋放而是被循環利用.因為建立連接是消耗較大的操作, 循環利用連接可以顯著的提高性能,因為可以減少新連接的建立.
比如一個應用程序需要連接一個由名字是EmployeeDB的DataSource對象代表的數據源, 通過緩沖池獲得連接的代碼演示如下:
Context ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("jdbc/EmloyeeDB");
Connection con = ds.getConnection("passWord","username");
因為連接的數據源不同所以和上面的例子中的名字不一樣. DataSource.getConnction方法返回的連接是否被緩存完全依賴於該DataSource對象的實現方式. 如果它將用於支持連接緩沖的中間層服務器(Middle TIEr Server), 則DataSource對象將自動返回將被緩存、循環利用的連接.
基本上不需要改變任何代碼就可以獲得緩沖池連接. 唯一需要注意的就是(我們已經這樣做了:P),需要在finally塊中釋放連接,這應該是釋放所有連接的較好方法.這樣, 即使拋出了異常, 連接也會還給連接緩沖池:
finally{
if(con != null) con.close();
}
finally塊保證了連接的循環利用.
★ Distributed Transactions(分布式交換)
獲得用於分布式交換的情形類似於獲得緩沖池連接. 差別仍然是DataSource對象的實現方式, 而不是獲得連接程序代碼的不同.
假定DataSource類被實現為用於中間件的分布式交換設施,下面的代碼將獲得用於分布式交換的連接:
Context ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("jdbc/EmloyeeDB");
Connection con = ds.getConnection("passWord","username");
出於性能的考慮, 用於獲得分布式交換的連接的DataSource對象差不多總是會同時實現緩沖池連接.
從程序員的角度來看, 獲得普通連接和獲得用於分布式交換的連接之間沒有區別. 唯一的不同是交換界限(什麼時候開始,什麼時候結束)由交換管理器在後台處理. 應用程序不應該做任何妨礙交換管理器的事情. 所以程序不能直接調用commit或者rollback方法, 不能設置auto-commit模式.
下面幾行代碼中con是可用於分布式交換的Connection對象, 演示了在con參與分布式交換是不能作的事情:
con.commit();
or
con.rollback();
or
con.setAutoCommit(true);
普通連接默認打開auto-commit模式. 用於分布式交換的連接對象默認關閉auto-commit模式. 應注意的是用於分布式交換的連接也可以用於非分布式交換模式, 交換邊界的限制僅在連接是分布式交換一部分是有效.
實現支持連接緩沖池的DataSource對象,需要實現ConnectionPoolDataSource對象, 三層構架的中間件的連接緩沖模塊將會使用它. 同樣, 實現支持分布式交換的DataSource對象也需要實現XADataSource對象, 中間件的分布式交換構件會使用該對象.
ConnectionPoolDataSource和XADataSource對象對程序員而言是完全透明的, 應有驅動程序廠商提供.
★ Rowsets
RowSet對象是一系列rows的容器. 根據不通的目的,可以通過多種方式實現. RowSet接口和其相關接口與JDBC 2.0標准擴展的其他部分的差別是它們不是驅動程序實現的一部分. RowSet對象在驅動程序的上層實現,可以被任何人實現.
任何rowset類型都要實現RowSet接口(繼承了ResultSet接口). 所以RowSet對象擁有ResultSet對象的所有功能:可以用getXXX方法取值,用updateXXX方法更新, 移動游標, 執行其他相關任務.
當然rowset也有其新功能.作為JavaBeans組件, RowSet對象提供了方法監聽屬性的get/set.其中一個屬性是command串,這個屬性往往是一個查詢,RowSet接口提供可設置command屬性和執行之的方法. 這意味這RowSet對象能夠執行自己的檢索命令用查詢結果填充自己的內容. 或者RowSet對象可以實現用來使用任何表格式的數據源填充自己, 而不是局限於關系數據庫.
從數據源取得數據後, RowSet對象可以斷開於數據源的連接,這使得該對象很小(如果數據量特別不大). rowset也可以序列化. 所以rowset很小並可以序列化, 一個斷開連接的rowset是傳送數據給瘦客戶機的理想工具.
rowset可以被更新,然後重新連接數據源以傳送更新的值. 如果設置了監聽者, 當rowset中的游標被移動和內容變化時,會通知監聽者.
如, 圖形界面組件(如條圖)可以被注冊為監聽者,當rowset上有事件發生將會同志它, 它可以重畫自身反映變化.
