1

TPLでのCancellationTokenのサポートについては知っていますが、（IMO）は、適切なtoken.ThrowifCancellationRequested（）がある場合にのみ機能します。これは、私のシナリオでは不可能です。

これを達成するための（スレッドを完全に中止する以外の）他のエレガントな方法はありますか？

スレッドのトランザクション状態は気にしません。スレッドがどのような状態で停止/キャンセルされたかは関係ありません。

ご関心をお寄せいただきありがとうございます。

詳細：新しいスレッド（タスク/スレッドプール/スレッド）を生成して、複数のストアドプロシージャを呼び出して100万近くのレコードをフェッチするAPIを呼び出す必要があります。次に、各レコードに装飾（ビジネス計算）を行います。最後に、このAPIは、ビジネス上重要なレポートであるデータテーブルを返します。必要に応じて、この処理を途中でキャンセルするオプションをユーザーに提供したいと思います。たとえば、フィルターのセットが間違って設定されている場合。APIは読み取り専用操作のみを実行するため、トランザクション管理は必要ありません。

4

1 に答える 1

0

これを適切に行うには、タスク クラスでキャンセル トークンを介してビルドアップ メソッドを使用するか、バックグラウンド ワーカーのキャンセルを使用する必要があります。または、volatilebool を使用して、ユーザー リクエストがキャンセルされたかどうかを確認することもできます。ただし、volatileブールは異なるアーキテクチャ (シングル/マルチ プロセッサ) 間で一貫して動作しません。*ResetEventまたは、キャンセルが呼び出されたことを示すために s を使用することもできます。これはすべて API 自体で行う必要があります。そうしないと、キャンセル条件を確認するタイミングをどのように知ることができるでしょうか? 勝手にキャンセルすることはできません。

もちろん、Abortスレッドを呼び出さないでください。これは悪であり、アプリケーション全体を未定義の状態にする可能性があります。アプリケーション全体を再起動する予定がない限り、呼び出さないでください。

ボーナスの提案

また、データベース側ですべての処理作業を行うことも検討してください。クライアント側に非常に少量のレコードしか持ち込まないでください。たとえば、1k が適切な実用的なしきい値です。多くのユーザーがさまざまなレポートを要求し、すべてがサーバーにそれほど多くの負荷をかける状況を考えてみましょう。これはうまくスケーリングできません。さらに、サーバーはデータ処理に関して非常に効率的であり、サーバー側でデータを保持しています。多くの最適化が行われています (CPU ライン キャッシング、高速メモリ アクセスなど)。

于 2012-10-29T07:37:28.797 に答える