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 資源，則會導致命名衝突或可能會出現試探性失敗。