これは、構成マネージャー・プロキシー (CMP) アプリケーションの開発という、より大きなタスクの一部で、CMP の拡張機能の 1 つです。
CMP を使用して、同じ構成マネージャーに対する複数の要求を一緒にグループ化し、それらを単一の作業単位として実行依頼することができます。
バッチを開始するには、アプリケーションが ConfigManagerProxy ハンドルで beginUpdates() メソッドを呼び出す必要があります。 これは、別の指示が通知されるまで、構成マネージャーに対して状態変更要求を実行依頼しないように CMP に指示します。 sendUpdates() メソッドは、最後の beginUpdates() 呼び出し以降に受け取った要求をバッチとして実行依頼するように CMP に指示します。また、clearUpdates() を使用して、構成マネージャーにバッチを実行依頼しないで廃棄することができます。 isBatching() メソッドを使用して、バッチが現在進行中かどうかを判断することができます。 それぞれの CMP ハンドルごとに 1 つのバッチだけが進行できることに注意してください。
バッチ・メソッドを使用する利点の 1 つは、バッチ中に、その他のアプリケーションでは構成マネージャーによって処理されるメッセージがないことを保証することです。 構成マネージャーがバッチ要求を受け取ると、各要求をバッチに追加された順序 (FIFO) でバッチ処理し、その他の CMP アプリケーションからの要求はバッチ全体が完了するまで処理されません。
BrokerProxy b2 = topology.createBroker("B2", "QMB2"); ExecutionGroupProxy e = b2.createExecutionGroup("default"); b2.deploy();
バッチ・メソッドを使用しないで、これらのアクションを成功させることは保証できません。 例えば、各コマンドが別の方法で成功するとしても、2 番目の (おそらくリモート) アプリケーションは、ブローカー B2 が最初のアプリケーションによって作成された後で、他の 2 つのコマンドが処理される前に、それを削除することができます。
cmp.startUpdates(); BrokerProxy b2 = topology.createBroker("B2", "QMB2"); ExecutionGroupProxy e = b2.createExecutionGroup("default"); b2.deploy(); cmp.sendUpdates();
バッチ・メソッドを使用する別の利点は、パフォーマンスです。 CMP は通常、1 つの WebSphere MQ メッセージを要求ごとに構成マネージャーに送信します。 たくさんの要求を立て続けに送信しなければならない状況では、トピック階層 (例えば、バッチ・メソッド) の作成は、要求を処理するためにかかる時間とメモリーという両面で、パフォーマンスに重大な影響を与えます。 各バッチ要求は単一の WebSphere MQ メッセージで送信されるため、各メソッドのオーバーヘッドは大幅に削減されます。
バッチ・モードではトランザクション (コミットとバックアウト) の能力を提供しません。バッチ内の一部の要求は成功し、それ以外は失敗する可能性があります。 構成マネージャーが要求をバッチで処理して失敗するとしても、次の要求もバッチでの処理を続けます。