0

を介して Quartz.NET でいくつかのジョブをチェーンしようとしていJobChainingJobListenerます。最初にいくつかの永続的なジョブを作成します (SQL Server で ADO JobStore を使用している間)。この部分はうまく機能します。ジョブは Quartz.NET の再起動後も表示されます。

リスナーを使用してジョブをチェーンするとScheduler.ListenerManager.AddJobListener(listener, matchers)正しく起動しますが、その定義をデータベースで永続化することはできません。サーバーを再起動するたびに、すべてのリスナーを再度定義する必要があります。

DB テーブルを見ると、リスナー用のテーブルはなく、コードにListenerManagerImplはリスナーの永続性のヒントも含まれていません。

リスナーの耐久性を追加し、サーバーの再起動時にグローバル リスナー ディクショナリをリロードする予定です。それを行う前に、プロジェクトがまだそうしていない理由があるかどうか疑問に思っていますか? Quartz.NET がどれだけ成熟しているかを考えると、誰かが既にこれに遭遇しているので、何かが足りないようです。

リスナーの耐久性を実装する際の落とし穴を指摘してもらえますか?

4

1 に答える 1

0

Quartz の観点からすると、リスナーは単なる構成の問題です。ライブラリのジョブ ストア タイプやその他の設定を構成するのと同じように。通常、リスナーはステートレスであるため、呼び出しと可能なジョブ処理ノード間で保持する必要がある状態を保持するトリガーやジョブとは異なり、永続化サービスは必要ありません。

適切な構成管理計画がある場合、これは問題になりません。セットアップの他の側面と同じように、リスナーの構成を処理するだけです。再起動の間にストレージが必要な状態管理がリスナーにある場合、それは別の話です。次に、当然、カスタムの永続性が必要になります。

于 2013-11-12T06:41:56.143 に答える