weblogic DataSource 配置注意事項 .

weblogic 建立datasource時，配置注意事項，記錄一下weblogic 的doc。

事務選項

使用管理控制檯配置 JDBC 數據源時，WebLogic Server 會根據 JDBC 驅動程序的類型自動選擇特定的事務選項：

• 對於 XA 驅動程序，系統會自動選擇用於全局事務處理的兩階段提交協議。
• 對於非 XA 驅動程序，將按照定義支持本地事務，而且 WebLogic Server 會提供如下選項

  支持全局事務：（在默認狀況下處於選中狀態）若是要在全局事務中使用來自數據源的鏈接，則選中此選項，即便未選擇 XA 驅動程序也是如此。有關詳細信息，請參閱使用非 XA JDBC 驅動程序啓用對全局事務的支持。

  選中「支持全局事務」時，還必須爲 WebLogic Server 選擇在處理全局事務時要用於事務分支的協議：

  • 記錄上一個資源：使用此選項，會將使用鏈接的事務分支做爲事務中最後的資源進行處理，並將其做爲本地事務進行處理。兩階段提交（two-phase commit，簡稱 2PC）的提交記錄會插入資源自身的表中，且此結果肯定了全局事務準備階段的成功或失敗。與「仿真兩階段提交」相比，此選項具備一些性能優點和更高的數據安全性，但它具備某些限制。請參閱瞭解「記錄上一個資源」選項。

    注意：	多數據源使用的數據源不支持「記錄上一個資源」。

  • 仿真兩階段提交：使用此選項，使用鏈接的事務分支始終返回事務準備階段的成功信息。此選項提供了性能優點，但在某些失敗狀況下也存在破壞數據的風險。只有在應用程序可容許出現試探性狀況時才能選擇此選項。
  • 一階段提交：（在默認狀況下處於選中狀態）使用此選項，來自數據源的鏈接只能是全局事務的惟一參與者，而且該事務是使用一階段提交優化完成的。若是多個資源參與該事務，則事務管理器在 1PC 資源上調用XAResource.prepare時會引起異常。

使用非 XA JDBC 驅動程序啓用對全局事務的支持

若是在應用程序中使用全局事務，則應使用 XA JDBC 驅動程序在 JDBC 數據源中建立數據庫鏈接。若是某個 XA 驅動程序不可用於您的數據庫，或者您不但願使用 XA 驅動程序，那麼您應在數據源中啓用對全局事務的支持。若是應用程序知足如下任何一個條件，則也應啓用對全局事務的支持：

• 使用 WebLogic Server 中的 EJB 容器來管理事務
• 在一個事務中包括多個數據庫更新
• 在一個事務中訪問多個資源（如數據庫和 Java 消息服務 (JMS)）
• 在多個服務器（羣集或非羣集）上使用相同的數據源

瞭解「記錄上一個資源」選項

WebLogic Server 經過 JDBC 數據源支持「記錄上一個資源」（Logging Last Resource，簡稱 LLR）事務優化。LLR 是一個性能加強選項，使用該選項可以使一個非 XA 資源可以使用與 XA 一樣的 ACID 保證參與全局事務。LLR 是「上一個代理優化」的改進結果。它與「上一個代理優化」不一樣，由於它對於事務而言是安全的。LLR 資源對其事務工做使用本地事務。WebLogic Server 事務管理器準備事務中的全部其餘資源，而後根據 LLR 資源本地事務的結果肯定全局事務的提交決定。

LLR 優化經過如下方式提升性能：

• 免除了使用 XA JDBC 驅動程序鏈接到數據庫的需求。與非 XA JDBC 驅動程序相比，XA JDBC 驅動程序一般較爲低效。
• 減小了完成事務時所需的處理步驟，這也減小了網絡流量和磁盤 I/O 次數。
• 免除了在數據庫級別進行 XA 處理的需求

當爲 LLR 配置的數據源中的鏈接參與兩階段提交 (2PC) 全局事務時，WebLogic Server 事務管理器會經過如下方式完成事務：

• 在全部其餘（符合 XA 標準的）事務參與者上調用準備。
• 將一個提交記錄插入 LLR 參與者的表中（而不是基於文件的事務日誌中）。
• 提交 LLR 參與者的本地事務（包括事務提交記錄插入和該應用程序的 SQL 工做）。
• 在全部其餘事務參與者上調用提交。

LLR 數據源的編程注意事項和限制

可按照使用來自任何其餘數據源的 JDBC 鏈接的方式，在應用程序中使用來自啓用了 LLR 的數據源的 JDBC 鏈接：在開始某個事務以後，在 JNDI 樹中查找數據源，而後請求一個來自該數據源的鏈接。可是，使用 LLR 優化時，WebLogic Server 會在內部管理鏈接請求，並以不一樣於在 XA 事務中使用的處理方式來處理事務處理。

請注意如下事項：

• 使用 LLR 數據源進行編程時，必須在調用 LLR 數據源的 getConnection 以前啓動全局事務。若是在啓動全局事務以前調用 getConnection，則會使對該鏈接的全部操做都處於全局事務以外。
• 僅對每一個事務保留一個內部 JDBC LLR 鏈接，而且該鏈接將用於整個事務處理。
• 保留的鏈接始終承載在該事務的協調器服務器上。請確保該數據源已定位到協調服務器或羣集。
• 對於該事務中來自同名數據源的其餘 JDBC 鏈接請求，操做會路由到來自原始鏈接請求的已保留鏈接，即便後續請求是在該數據源的其餘實例（即部署在與爲第一個請求提供鏈接的原始數據源所在服務器不一樣的服務器上的數據源）上作出的，也是如此。請注意如下內容：
  • 在功能和性能方面，路由的 LLR 鏈接可能不如本地承載的 XA 鏈接。
  • 鏈接請求路由會限制併發事務的個數。最大併發 LLR 事務數等於協調器的 JDBC LLR 數據源的已配置大小 (MaxCapacity)。
  • 路由鏈接的功能少於本地鏈接的功能，可能會所以而致使失敗。具體地說，在查詢 ResultSet 中的非序列化「自定義」數據類型可能會失敗。
• 只有單個 LLR 數據源的實例能夠參與某個特定事務。單個 LLR 數據源可在多個 WebLogic 服務器上具備實例，若是兩個數據源具備相同的已配置名稱，則這兩個數據源會被認爲是相同的。若是檢測到多個 LLR 數據源實例，而且它們不是同一數據源的實例，則事務管理器會回滾事務。
• 實現weblogic.transaction.nonxa.NonXAResource接口的資源適配器（鏈接器）不能參與 LLR 資源也同時參與的全局事務，由於兩者都必須是事務中的最後一個資源。若是兩種資源類型都參與同一個事務，則在檢測到此衝突時，事務的commit()方法會引起javax.transaction.RollbackException。
• 因爲 LLR 鏈接對於數據庫處理使用單獨的本地事務，所以，在 LLR 處理過程當中，使用 XA 鏈接對同一數據庫進行的任何更改（和進行的任何鎖定）都將不可見，即便全部的處理都發生在同一全局事務中，也是如此。在某些狀況下，這可能會在數據庫中引發死鎖。在單個全局事務中不該在同一數據庫中混合 XA 和 LLR 處理。
• 來自某個 LLR 數據源的鏈接不能參與由外部事務管理器協調的事務，如由遠程對象請求代理或由 Tuxedo 啓動的事務。
• 全局事務不能跨至另外一個包含了與某個 LLR 數據源同名的數據源的舊式域。
• 對於 JDBC LLR 2PC 事務，若是事務數據太大，沒法裝入 LLR 表中，則事務將會失敗，並在提交期間生成一個回滾異常。若是在事務處理過程當中，您的應用程序添加了許多事務屬性，則會發生上述狀況。若是發生了上述狀況，那麼，數據庫管理員可手工建立一個具備更大的列的表。

LLR 數據源的管理注意事項和限制

配置啓用了 LLR 的 JDBC 數據源時，請考慮如下要求和限制：

• 對於每一個服務器，都有一個 LLR 表：
  • 多個 LLR 數據源可共享一個表。
  • 若是找不到該表，則 WebLogic Server 會自動建立該表。
  • 默認名稱爲WL_LLR_SERVERNAME。可在管理控制檯中，依次選擇服務器 > 配置 > 常規選項卡，在該選項卡上的「高級」選項下配置該表名。
• 若是在引導期間數據庫處於關閉狀態或 LLR 表不可訪問，則服務器將不會進行引導。
• 多個服務器不得共享同一個 LLR 表。引導會進行檢查，以確保域和服務器名稱與建立表時存儲在表中的域和服務器名稱相匹配。若是 WebLogic Server 檢測到多個服務器正在共享同一個 LLR 表，則 WebLogic Server 將關閉一個或多個服務器。
• LLR 支持服務器遷移和事務恢復服務遷移。要使用事務恢復服務遷移，請確保每一個 LLR 資源都會定位到羣集或羣集中的候選服務器組。請參閱「爲發生故障的羣集服務器恢復事務」。
• 在 JDBC 應用程序模塊中不容許使用 LLR 事務選項。
• 多數據源使用的數據源中不支持使用 LLR 事務選項。
• 若是在某個 LLR 數據源上使用了憑據映射，則全部映射的用戶都必須具備對該 LLR 表的寫權限。
• 不能使用 JDBC XA 驅動程序在 JDBC LLR 數據源中建立數據庫鏈接。若是 JDBC LLR 數據源中使用的 JDBC 驅動程序支持 XA，則會記錄一條警告消息，而且數據源會做爲徹底的 XA 資源（而不是做爲 LLR 資源）參與事務。
• 會在「NonXAResource」下跟蹤 LLR 資源的事務統計信息。

瞭解「仿真兩階段提交」事務選項

若是須要使用某個 JDBC 數據源來支持分佈式事務，但沒有符合 XA 標準的驅動程序可供您的 DBMS 使用，則可對某個數據源的「非 XA 驅動程序」選項選擇「仿真兩階段提交」，以便對來自該數據源的鏈接參與的事務仿真兩階段提交。此選項是「常規」選項卡（可經過依次選擇「JDBC 數據源」「配置」「常規」選項卡來訪問該選項卡）上的高級選項。

對「非 XA 驅動程序」選項選擇「仿真兩階段提交」（EnableTwoPhaseCommit設置爲true）時，非 XA JDBC 資源老是會在XAResource.prepare() 方法調用期間返回XA_OK。資源會嘗試提交或回滾其本地事務以響應後續的XAResource.commit() 或XAResource.rollback() 調用。若是資源提交或回滾失敗，則會致使一個試探性錯誤。應用程序數據可能會因爲試探性失敗而處於不一致狀態。

未在控制檯中對「非 XA 驅動程序」選項選擇「仿真兩階段提交」（EnableTwoPhaseCommit設置爲false）時，非 XA JDBC 資源會致使XAResource.prepare() 失敗。當僅有一個資源參與事務時，一階段優化將跳過XAResource.prepare()，而且在大多數狀況下，事務會成功提交。

注意：	對「非 XA 驅動程序」選項選擇「仿真兩階段提交」時，會存在破壞數據完整性的風險。BEA 建議使用符合 XA 標準的 JDBC 驅動程序或「記錄上一個資源」選項（而不是使用「仿真兩階段提交」選項）。請確保在啓用此選項以前考慮了這些風險。

該非 XA JDBC 驅動程序支持一般稱爲「JTS 驅動程序」，由於 WebLogic Server 在內部使用 WebLogic JTS 驅動程序以支持該功能。

使用非 XA 驅動程序仿真兩階段提交時的限制和風險

WebLogic Server 使用「仿真兩階段提交」數據源事務選項支持非 XA JDBC 資源參與全局事務，但會存在一些在設計應用程序（以使用這樣的數據源）時必須考慮的限制。由於非 XA 驅動程序不符合 XA/2PC 合同，而且僅支持一階段提交和回滾操做，因此 WebLogic Server（經過 JTS 驅動程序）必須進行妥協以容許資源參與由事務管理器控制的某個事務。

在對「非 XA 驅動程序」選項使用「仿真兩階段提交」以前，請考慮如下限制和風險：

試探性完成和數據不一致

對非 XA 資源選擇「仿真兩階段提交」(enableTwoPhaseCommit = true) 時，非 XA 資源的事務準備階段老是會成功。所以，非 XA 資源沒有真正地參與兩階段提交 (2PC) 協議，而且容易失敗。若是在準備階段以後，在非 XA 資源中發生故障，則非 XA 資源可能會在 XA 事務參與者要提交事務時回滾事務，從而致使試探性完成和數據不一致。

因爲存在破壞數據完整性的風險，因此，「仿真兩階段提交」選項僅應在可容許出現試探性狀況的應用程序中使用。

沒法恢復待定事務

由於非 XA 驅動程序僅對本地數據庫事務進行操做，因此，在有關外部事務管理器的數據庫中沒有事務待定狀態的概念。在非 XA 資源上調用XAResource.recover()時，該方法老是會返回 Xid（事務 ID）的一個空集，即便可能有須要提交或回滾的事務，也是如此。所以，那些在全局事務中使用非 XA 資源的應用程序沒法從系統故障中恢復過來，並沒有法保持數據完整性。

在多服務器配置中使用非 XA 資源時可能產生的性能損失

由於 WebLogic Server 依賴於與特定 JDBC 鏈接相關聯的數據庫本地事務來支持全局事務中的非 XA 資源，因此，當某個應用程序經過一個全局事務上下文在多個 WebLogic Server 實例中訪問同一 JDBC 數據源時，JTS 驅動程序會始終將 JDBC 操做路由到由該應用程序在事務中創建的第一個鏈接。例如，若是某個應用程序在一個服務器上啓動了某個事務，訪問非 XA JDBC 資源，而後對另外一個服務器進行遠程方法調用（remote method invocation，簡稱 RMI）並訪問某個使用同一底層 JDBC 驅動程序的數據源，則 JTS 驅動程序會識別出該資源具備與其餘服務器上的事務相關聯的鏈接，並會設置一個到第一個服務器上的實際鏈接的 RMI 重定向。對該鏈接的全部操做都會對創建在第一個服務器上的一個鏈接執行。此行爲可因爲與設置這些遠程鏈接和對一個物理鏈接進行 RMI 調用相關聯的開銷而致使性能損失。

僅一個非 XA 參與者

將某個非 XA 資源（其「仿真兩階段提交」處於選中狀態）註冊到 WebLogic Server 事務管理器時，會使用實現 XAResource 接口的類的名稱註冊該資源。由於其「仿真兩階段提交」處於選中狀態的全部非 XA 資源都對 XAResource 接口使用 JTS 驅動程序，因此，會使用同一名稱註冊全部參與某個全局事務的非 XA 資源（其「仿真兩階段提交」處於選中狀態）。若是在某個全局事務中使用多個非 XA 資源，則會致使命名衝突或可能會出現試探性失敗。