2

バッキングScheduledExecutorServiceを使用してスケジューラーのAPIに取り組んでいます。基本的な設計は、プロバイダーインスタンスをスケジューラーに登録することであり、スケジューラーは登録されたプロバイダーごとにScheduledFutureを維持します。プロバイダーは基本的に、起動タスクを取得する方法を知っているランナブルです。

私が抱えている問題は、予定されている未来をキャンセルするときにどうするかです。ScheduledFutureをキャンセルするAPIはブールパラメーターを取り、起動されているプロバイダーの中断を許可します。プロバイダーが強制終了されたときに、そのパラメーターの値とともにプロバイダーにアラートを送信することは理にかなっていると思います。これにより、必要なクリーンアップを実行できます。

ただし、ScheduledFutureをキャンセルする前に、プロバイダーインスタンスが強制終了されることをアラートすると、プロバイダーインスタンスは、そのパラメーターの値に関係なく、実行が完了するまでブロックすることでAPIを破壊する可能性があります。

その一方で、その値をtrueに設定してcancelが呼び出され、ScheduledFutureがキャンセルされてから、プロバイダーインスタンスに強制終了が通知されると、それに対して何かを行う機会が失われる可能性があります。

注：プロジェクトの要件により、Quartzを使用できません。そうでなければ、私はそれを使用したでしょう。私の質問はAPI設計に関するものなので、別のフレームワークを使用するように言って応答しないでください。

何か案は？

4

3 に答える 3

4

技術的には、これは API というより SPI に近いのではないでしょうか? 結果として、より多くの実装者を期待できると思うので、閉鎖を通知します。ちょっとしたヘッジとして、通知がデフォルトで何もしないことも確認します。リスナーを使用する場合は、このイベントのプロバイダーを自動的に登録しないでください。常に特定のメソッドを呼び出す場合は、その呼び出しに対して何もしない抽象基本クラスを提供します。

SPI の実装者が増えることを期待する理由は次のとおりです。

タスクをスケジュールする場合は、ScheduledExecutor API を使用します。アプリケーション プログラマーとして、満足したいユースケースがあり、それがどのように行われるかという内部の仕組みには関心がないようにしています。その結果、API は一般的に非常に防御的にコーディングする必要があると思います。

Provider は明らかに SPI です。クラス名「Provider」が大きなヒントです。使用方法を正確に認識しており、低レベルの詳細がすべてです。デフォルトの実装は私が望むことをしないので、私はそれを具体的に実装しています。私は最大限の柔軟性を求めていますが、多少の努力は必要です。アプリケーション プログラマーがこれを作成することを期待すべきではありません。ただし、ある実装を別の実装よりも選択する可能性があります。

于 2012-05-28T14:27:57.123 に答える
0

この種のサービスを自分でコーディングする代わりに、Quartz-Schedulerを使用することを強くお勧めします。スケジュールされたジョブのキャンセルをサポートしています(他の多くのものの中でも)。

于 2012-05-26T16:38:17.263 に答える
0

ここで誤解しているかもしれませんが、あなたはこれを考えすぎていませんか？

将来実行される予定のタスクをキャンセルしたいのに、プロバイダーがまだその作業の実行を開始していない場合、なぜ何かをクリーンアップする必要があるのでしょうか?

于 2012-05-26T16:26:34.930 に答える