Java串連資料

Connection   對象代表與資料庫的串連。串連過程包括所執行的   SQL   語句和在該串連上所返回的結果。一個應用程式可與單個資料庫有一個或多個串連，或者可與許多資料庫有串連。
2.1.1   開啟串連與資料庫建立串連的標準方法是調用   DriverManager.getConnection
方法。該方法接受含有某個   URL   的字串。DriverManager   類（即所謂的   JDBC   管理層）將嘗試找到可與那個   URL   所代表的資料庫進行串連的驅動程式。DriverManager   類存有登入的   Driver   類的清單。當調用方法   getConnection   時，它將檢查清單中的每個驅動程式，直到找到可與   URL   中指定的資料庫進行串連的驅動程式為止。Driver   的方法   connect   使用這個   URL   來建立實際的串連。
使用者可繞過   JDBC   管理層直接調用   Driver   方法。這在以下特殊情況下將很有用：當兩個磁碟機可同時串連到資料庫中，而使用者需要明確地選用其中特定的磁碟機。但一般情況下，讓   DriverManager   類處理開啟串連這種事將更為簡單。
下述代碼顯示如何開啟一個與位於   URL   "jdbc:odbc:wombat "   的資料庫的串連。所用的使用者識別碼為   "oboy "   ，口令為   "12Java "：  
String   url   =   "jdbc:odbc:wombat ";
Connection   con   =   DriverManager.getConnection(url,   "oboy ",   "12Java ");
2.1.2   一般用法的   URL由於   URL   常引起混淆，我們將先對一般   URL   作簡單說明，然後再討論   JDBC   URL。
URL（統一資源定位器）提供在   Internet   上定位資源所需的資訊。可將它想象為一個地址。
URL   的第一部份指定了訪問資訊所用的協議，後面總是跟著冒號。常用的協議有   "ftp "（代表“檔案傳輸通訊協定”）和   "http "   （代表“超文字傳輸通訊協定 (HTTP)”）。
如果協議是   "file "，表示資源是在某個本地檔案系統上而非在   Internet   上（下例用於表示我們所描述的部分；它並非   URL   的組成部分）。
ftp://javasoft.com/docs/JDK-1_apidocs.zip
http://java.sun.com/products/jdk/CurrentRelease
file:/home/haroldw/docs/books/tutorial/summary.html
URL   的其餘部份（冒號後面的）給出了資料資源所處位置的有關資訊。如果協議是   file，則   URL   的其餘部份是檔案的路徑。對於   ftp   和   http   協議，URL   的其餘部份標識了主機並可選地給出某個更詳盡的地址路徑。例如，以下是   JavaSoft   首頁的   URL。該   URL   只標識了主機：  
http://java.sun.com從該首頁開始瀏覽，就可以進到許多其它的網頁中，其中之一就是
JDBC   首頁。JDBC   首頁的   URL   更為具體，它看起來類似：   http://java.sun.com/products/jdbc
2.1.3   JDBC   URL   JDBC   URL   提供了一種標識資料庫的方法，可以使相應的驅動程式能識別該資料庫並與之建立串連。實際上，驅動程式編程員將決定用什麼   JDBC   URL   來標識特定的驅動程式。使用者不必關心如何來形成   JDBC   URL；他們只須使用與所用的驅動程式一起提供的   URL   即可。JDBC   的作用是提供某些約定，驅動程式編程員在構造他們的   JDBC   URL   時應該遵循這些約定。
由於   JDBC   URL   要與各種不同的驅動程式一起使用，因此這些約定應非常靈活。首先，它們應允許不同的驅動程式使用不同的方案來命名資料庫。例如，   odbc   子協議允許（但並不是要求）   URL   含有屬性值。第二，JDBC   URL   應允許驅動程式編程員將一切所需的資訊編入其中。這樣就可以讓要與給定資料庫對話的   applet   開啟資料庫連接，而無須要求使用者去做任何系統管理工作。
第三，   JDBC   URL   應允許某種程度的間接性。也就是說，JDBC   URL   可指向邏輯主機或資料庫名，而這種邏輯主機或資料庫名將由網路命名系統動態地轉換為實際的名稱。這可以使系統管理員不必將特定主機聲明為   JDBC   名稱的一部份。網路命名服務（例如   DNS、   NIS   和   DCE   ）有多種,而對於使用哪種命名服務並無限制。JDBC   URL   的標準文法如下所示。它由三部分組成，各部分間用冒號分隔：  
jdbc: <   子協議   > : <   子名稱   > JDBC   URL   的三個部分可分解如下：   jdbc   ─   協議。JDBC   URL   中的協議總是   jdbc。
<子協議>   ─   驅動程式名或資料庫連接機制（這種機制可由一個或多個驅動程式支援）的名稱。子協議名的典型樣本是   "odbc "，該名稱是為用於指定   ODBC   風格的資料資源名稱的   URL   專門保留的。例如，為了通過   JDBC-ODBC   橋來訪問某個資料庫，可以用如下所示的   URL：  
jdbc:odbc:fred本例中，子協議為   "odbc "，子名稱   "fred "   是本地ODBC   資料資源。
如果要用網路命名服務（這樣   JDBC   URL   中的資料庫名稱不必是實際名稱），則命名服務可以作為子協議。例如，可用如下所示的   URL   ：  
jdbc:dcenaming:accounts-payable本例中，該   URL   指定了本地   DCE   命名服務應該將
資料庫名稱   "accounts-payable "   解析為更為具體的可用於串連真實資料庫的名稱。 <子名稱>   ─   一種標識資料庫的方法。子名稱可以依不同的子協議而
變化。它還可以有子名稱的子名稱（含有驅動程式編程員所選的任何內部文法）。使用子名稱的目的是為定位元據庫提供足夠的資訊。前
例中，因為   ODBC   將提供其餘部份的資訊，因此用   "fred "   就已足夠。然而，位於遠程伺服器上的資料庫需要更多的資訊。例如，如果資料庫是通過   Internet   來訪問的，則在   JDBC   URL   中應將網路地址作為子名稱的一部份包括進去，且必須遵循如下所示的標準   URL   命名規範：  
//主機名稱:連接埠/子協議假設   "dbnet "   是個用於將某個主機串連到   Internet   上的協議，則   JDBC   URL   類似：
jdbc:dbnet://wombat:356/fred   2.1.4   "odbc "   子協議
子協議   odbc   是一種特殊情況。它是為用於指定   ODBC   風格的資料資源名稱的   URL   而保留的，並具有下列特性：允許在子名稱（資料資源名稱）後面指定任意多個屬性值。odbc   子協議的完整文法為：   jdbc:odbc: <   資料資源名稱   > [; <   屬性名稱   > = <   屬性值   > ]*因此，以下都是合法的   jdbc:odbc   名稱：   jdbc:odbc:qeor7jdbc:odbc:wombat
jdbc:odbc:wombat;CacheSize=20;ExtensionCase=LOWER
jdbc:odbc:qeora;UID=kgh;PWD=fooey2.1.5   註冊子協議驅動程式編程員可保留某個名稱以將之用作   JDBC   URL   的子協議名。
當   DriverManager   類將此名稱加到登入的驅動程式清單中時，為之保留該名稱的驅動程式應能識別該名稱並與它所標識的資料庫建立串連。例如，odbc   是為   JDBC-   ODBC   橋而保留的。樣本之二，假設有個   Miracle   公司，它可能會將   "miracle "   註冊為串連到其   Miracle   DBMS   上的   JDBC   驅動程式的子協議，從而使其他人都無法使用這個名稱。JavaSoft   目前作為非正式代理程式負責註冊   JDBC   子協議名稱。要註冊某個子協議名稱，2.1.6   發送   SQL   語句串連一旦建立，就可用來向它所涉及的資料庫傳送   SQL   語句。JDBC對可被發送的   SQL   語句類型不加任何限制。這就提供了很大的靈活性，即允許使用特定的資料庫語句或甚至於非   SQL   語句。然而，它要
求使用者自己負責確保所涉及的資料庫可以處理所發送的   SQL   語句，否則將自食其果。例如，如果某個應用程式試圖向不支援儲存程式的   DBMS   發送儲存程式調用，就會失敗並將拋出異常。JDBC   要求驅動程式應至少能提供   ANSI   SQL-2   Entry   Level   功能才可算是符合   JDBC   標準TM   的。這意味著使用者至少可信賴這一標準層級的功能。JDBC   提供了三個類，用於向資料庫發送   SQL   語句。Connection   介面中的三個方法可用於建立這些類的執行個體。下面列出這些類及其建立方法：  
Statement   ─   由方法   createStatement   所建立。Statement   對象用於發送簡單的   SQL   語句。  
PreparedStatement   ─   由方法   prepareStatement   所建立。
PreparedStatement   對象用於發送帶有一個或多個輸入參數（   IN   參數）
的   SQL   語句。PreparedStatement   擁有一組方法，用於設定   IN   參數的值。
執行語句時，這些   IN   參數將被送到資料庫中。PreparedStatement   的實
例擴充了   Statement   ，因此它們都包括了   Statement   的方法。
PreparedStatement   對象有可能比   Statement   對象的效率更高，因為它已被先行編譯過並存放在那以供將來使用。  
CallableStatement   ─   由方法   prepareCall   所建立。CallableStatement   對象
用於執行   SQL   儲存程式   ─   一組可通過名稱來調用（就象函數的調用那樣）的
SQL   語句。CallableStatement   對象從   PreparedStatement   中繼承了用於
處理   IN   參數的方法，而且還增加了用於處理   OUT   參數和   INOUT   參數的方法。  
以下所列提供的方法可以快速決定應用哪個   Connection   方法來建立不同類型的   SQL   語句：   createStatement   方法用於：
簡單的   SQL   語句（不帶參數）   prepareStatement   方法用於：   帶一個或多個   IN   參數的   SQL   語句   經常被執行的簡單   SQL   語句
prepareCall   方法用於：   調用已儲存過程2.1.7   事務事務由一個或多個這樣的語句組成：這些語句已被執行、完成並被提交或還原。當調用方法   commit   或   rollback   時，當前事務即告就結束，另一個事務隨即開始。
預設情況下，新串連將處於自動認可模式。也就是說，當執行完語句後，將自動對那個語句調用   commit   方法。這種情況下，由於每個語句都是被單獨提交的，因此一個事務只由一個語句組成。如果禁用自動認可模式，事務將要等到   commit   或   llback   方法被顯式調用時
才結束，因此它將包括上一次調用   commit   或   rollback   方法以來所有執行過的語句。對於第二種情況，事務中的所有語句將作為組來提交或還原。方法   commit   使   SQL   語句對資料庫所做的任何更改成為永久性的，它還將釋放事務持有的全部鎖。而方法   rollback   將棄去那些更改。
有時使用者在另一個更改生效前不想讓此更改生效。這可通過禁用自動認可並將兩個更新群組合在一個事務中來達到。如果兩個更新都是成功
，則調用   commit   方法，從而使兩個更新結果成為永久性的；如果其中之一或兩個更新都失敗了，則調用   rollback   方法，以將值恢複為進行更新之前的值。
大多數   JDBC   驅動程式都支援事務。事實上，符合   JDBC   的驅動程式必須支援事務。DatabaseMetaData   給出的資訊描述   DBMS   所提供的事務支援水平。2.1.8   交易隔離等級如果   DBMS   支援交易處理，它必須有某種途徑來管理兩個事務同時對一個資料庫進行操作時可能發生的衝突。使用者可指定交易隔離等級，以指明   DBMS   應該花多大精力來解決潛在衝突。例如，當事務更改了某個值而第二個事務卻在該更改被提交或還原前讀取該值時該怎麼辦   假設第一個事務被還原後，第二個事務所讀取的更改值將是無效的，那麼是否可允許這種衝突？   JDBC   使用者可用以下代碼來指示   DBMS   允許在值被提交前讀取該值（“dirty   讀取”），其中   con   是當前串連：  
con.setTransactionIsolation(TRANSACTION_READ_UNCOMMITTED);
交易隔離等級越高，為避免衝突所花的精力也就越多。Connection   介面定義了五級，其中最低層級指定了根本就不支援事務，而最進階別則指定當事務在對某個資料庫進行操作時，任何其它事務不得對那個事務正在讀取的資料進行任何更改。通常，隔離等級越高，應用程式執行的速度也就越慢（由於用於鎖定資源耗費增加了，而使用者間的並行作業減少了）。在決定採用什麼隔離等級時，開發人員必須在效能需求和資料一致性需求之間進行權衡。當然，實際所能支援的層級取決於所涉及的   DBMS   的功能。
當建立   Connection   對象時，其交易隔離等級取決於驅動程式，但通常是所涉及的資料庫的預設值。使用者可通過調用   setIsolationLevel方法來更改交易隔離等級。新的層級將在該串連過程的剩餘時間內生效。要想只改變一個事務的交易隔離等級，必須在該事務開始前進行設定，並在該事務結束後進行複位。我們不提倡在事務的中途對交易隔離等級變更，因為這將立即觸發   commit   方法的調用，使在
此之前所作的任何更改變成永久性的。