模板
教程
環境
性能
功能
管理
WebSphere Enterprise Scheduler 規劃管理（2）
恢復和延遲
調度程序使用一種固定延遲計算時間。當由于資源不足或具有長時間運行任務而使調度程序過載時，任務就會推遲運行（請參考性能部分的任務延遲）。如果重復執行的任務的執行被推遲，那么下次執行時間就會根據實際的執行時間來計算。圖 8 說明了使用 SIMPLE 日歷（它會根據相關的絕對時間增量來計算執行時間）時，在中斷或延遲期間任務的執行時間會發生什么變化。底部的箭頭指明在沒有延遲的情況下任務的執行方式。頂部的箭頭指明實際的執行時間是哪些（假定任務 2 和 3 由于中斷或延遲而沒有執行）。此處，正常情況下會在 2:00 時執行的任務則在 3:15 當調度程序變為可用時立即執行。
如果調度程序失敗，一旦它重新啟動以后，所有的任務就會立即在期限以內運行。所有已經在運行的任務，如果還沒有成功完成，就會再次運行（它的已提交事務）。重復次數會反映出已經成功運行的任務（更多細節請參考EJB 事務注意事項）。
可擴展性
隨著處理器以及與調度程序相關聯的 WorkManager 中可用的警報的增加，調度程序將會垂直地擴展。利用 Tivoli® Performance Analyzer（參見性能），可以識別警報延遲并添加更多的處理器和警報。
調度程序并不具有自然地進行水平擴展的能力。因為調度程序不能夠自然地分割，需要依靠管理員或開發人員分割應用程序給多個的調度程序，并創建多余的調度程序來訪問不同的數據庫或表，或分割調度程序正在執行的工作，從而為調度程序守護增加可用資源。
分割的調度程序守護
為了闡述管理員如何將一個調度程序分割成兩個部分，我們借助于圖 9 來說明。圖中在一個單元內有四個節點，每個節點各有一個服務器。有一個應用程序安裝在這一單元中，并部署在所有這四個服務器上。每個服務器上都定義了一個調度程序資源。每個調度程序資源所引用的 WorkManager 和 DataSource 都在單元作用域中做了配置。
在正常情況下，本場景中所有的調度程序都會和同樣的數據庫表進行通信。然而，在這種情況下，Nodes B 和 C 中的服務器訪問的是前綴為 MAIN1 的表，而 Nodes A 和 D 則訪問前綴為的 MAIN2 表。這意味著 Nodes B 和 C 中的調度程序有冗余，并獨立于 Nodes A 和 D 中的冗余調度程序。在這種配置下，應用程序保留原樣，但調度程序工作被分割在兩個不同的節點上。雖然可以將 Nodes A 和 B 合并形成 Node X，將 Nodes C 和 D 合并形成 Node Y，但也很難保證一個節點不會從 MAIN1 和 MAIN2 得到兩個租用權。調度程序服務并沒有“優先”守護的理念。在本場景中，如果要強制使哪一個調度程序獲取租用權，則管理員需要執行以下操作之一：
延遲啟動某個輪詢守護程序，直到所要的輪詢守護程序已處于活動狀態并獲得了租用權（執行它的首次輪詢），或者
停止某個輪詢守護程序，直到一個冗余獲得租用權，這所花的時間與輪詢間隔一樣多（參見強制獲得租用權）。
在這一類場景中，應用程序開發人員和管理員必須理解：由于已經將調度程序作了分割，應用程序只能看到所調度的任務的一個子集。因此，應用程序在管理已完成調度的任務時需要查看兩個分區中的任務。例如，如果有個任務在 Node A 中創建，而操作人員需要取消這一任務，該操作人員就需要知道它是在 Node A 中創建的，或者試著在所有節點上取消它。
帶有強制租用權的分割的調度程序
我們可能希望編寫這樣的應用程序：對不同的任務進行分類并在每個子集在運用不同的分割的調度程序。例如，創建一個調度程序來處理來自奇數 ID 號或者偶數 ID 號的員工的請求。再說一次，確保每個節點獲得一個租用權的惟一方法是強制獲得租用權（參見強制獲得租用權）。
強制獲得租用權
如果創建了一個調度程序集群，我們可能希望讓每個服務器擁有一個租用權以供調度程序使用（以便所有的任務都在該服務器上運行）；例如，如果服務器 big_server 擁有足夠的容量來運行這些任務。您可以使用以下的方法之一來強制 big_server 擁有租用權：
啟動調度程序集群，一次一個服務器，而 big_server 是第一個啟動的服務器（真正的服務器集群或者只是使用同樣的調度程序配置的服務器集合）。
如果服務器已經激活，則可在所有的調度程序服務器上調用 WASScheduler MBean's stopDaemon 操作。這樣即可釋放租用權。一旦所有的守護程序均已停止，則會調用 big_server 上的 startDaemon 操作，然后才是其他服務器。這樣就可以使 big_server 獲得租用權。
分割應用程序
比較簡單而且是希望獲得的分割方法是只將應用程序分割成兩塊。其中一塊負責調度任務，另一塊負責運行所調度的任務。此處，執行任務的應用程序可以位于不同集群上。在圖 11 中，用于創建和管理任務的應用程序是在一組節點上（可以是一個集群），而運行任務的應用程序（BeanTasksApp.ear）則在一個獨立的集群上。因為任務是 EJB 的，而且它們處于獨立的應用程序和集群上，所以調度程序使用工作負載管理（Workload Management，WLM）來分發和平衡每個集群成員的工作量。
服務配置
每個安裝調度程序的應用服務器都有一個調度程序服務配置面板。該服務配置面板能夠簡單地為給定的應用服務器啟用和禁用調度程序服務。如果禁用了這一選項，則給定的服務器的所有調度程序活動均變為不可用。不會運行輪詢守護程序，同時調度程序配置資源的 JNDI 查找也不可用。擁有引用 com.ibm.websphere.Scheduler 的資源的應用程序也會加載失敗。這一選項只可在兩個場景中使用：
根本就沒使用調度程序。
需要在一個服務器上禁用輪詢守護程序。
數據庫配置
調度程序作用一個用戶定義的數據庫來保存所創建的任務。然后輪詢守護程序使用這個數據庫來確定哪些任務要運行以及什么時候運行。調度程序服務數據庫表是通過編輯和執行客戶的數據庫管理系統提供的 Data Definition Language（DDL）（或 SQL）文件來創建的。WebSphere Business Integration Server Foundation V5.1 Information Center中提供了創建表的細節。
這一部分描述了調度程序管理員在配置調度程序和各自的數據庫時需要知道的一些事項，以及調度程序開發人員和構架師在開發應用程序時需要知道的一些事項。
調度程序交互
調度程序使用四個不同的線程來與數據庫交互：
使用 com.ibm.websphere.scheduler.Scheduler 接口方法的應用程序線程。
輪詢守護線程。
運行任務的每個警報線程。
每個調度程序使用四個表（每個表均帶有調度程序配置的表前綴）：
TASK：包含創建的所有任務。每個 Scheduled 任務占據表中的一行。
TREG：包含調度程序在內部使用的各種配置信息。
LMGR：包含租用權管理器信息。
LMPR：包含租用權管理器信息。
所有的數據庫訪問都是使用每個線程對應單個的共享連接、只讀的事務隔離以及行級鎖。
估計數據庫大小
只有一個表存儲大量數據，那就是 TASK 表。每個調度任務均對應表中的一行。每個調度任務都有最小的字節數 535。表中有一個 Binary Large Object（BLOB）類是用于存儲任意數據的，包括特定任務的數據：對于 BeanTaskInfo 對象，它是 TaskHandlerHome 的主句柄；對于 MessageTaskInfo 對象，它包括每個包含有消息數據的設置字段。BLOB 列也包括來自與調度程序相關聯的 WorkManager 的 J2EE 上下文信息。例如，如果在 WorkManager 中啟用了國際化服務，那么國際化安全上下文信息就會存儲在 BLOB 中。BLOB 典型的大小是 3000 — 5000 字節。
連接
管理員必須確保數據庫和 DataSource 的最大連接數有足夠的連接來用于訪問調度程序 API 的輪詢守護線程、警報線程和 J2EE 應用程序線程。所有的數據庫連接共享一個調度程序。每個調度程序所使用的最大同時連接數可以由以下的公式來計算：
?。? 輪詢守護線程）＋（x-1 警報線程）＋（y API 線程）
因此，如果您有一個調度程序，它配置的 WorkManager 具有 5 個警報線程，那么應用程序與調度程序 API 相交互使用的當前線程數最大為兩個，而 DataSource 和數據庫（只用于調度程序）所需要的連接總數為：1+ (5-1) + 2 = 7 個連接。
事務
與數據庫的每次交互都是在事務中完成的。如果在調用調度程序 API 時有一個全局事務活動在線程上，那么就會使用同一個事務。而如果全局事務并不在線程上活動，則 API 會創建自己的全局事務。所有的數據庫交互和 EJB 交互會在同一個事務中發生。因此，在為調度程序選擇使用 1-Phase Commit（PC）或 2-PC 的可用數據庫資源時，以及選擇 EJB 中的恰當事務屬性時，記住這一點是很重要的。
在大多數環境下，調度程序配置必須使用 2-PC、XA 可用的 DataSource。而 1-PC 和非 XA 可用的 DataSource 只在以下條件之一成立時才可用：
Schedu
原文轉自：http://www.anti-gravitydesign.com
