weblogic DataSource 配置注意事項

標籤：des   style   blog   http   io   使用   java   ar   strong   

本文轉自：http://blog.csdn.net/yangjun2/article/details/7044736

目錄

1.  事務選項
1. 使用非 XA JDBC 驅動程式啟用對全域事務的支援
2. 瞭解記錄上一個資源選項
1. LLR 資料來源的編程注意事項和限制
2. LLR 資料來源的管理注意事項和限制
3. 瞭解模擬兩階段交易認可事務選項
1. 使用非 XA 驅動程式模擬兩階段交易認可時的限制和風險
1. 試探性完成和資料不一致
2. 無法恢複待定事務
3. 在多伺服器配置中使用非 XA 資源時可能產生的效能損失
4. 僅一個非 XA 參與者

 

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

 

weblogic DataSource 配置注意事項