Beakerテストシステムには、レシピで定義されたさまざまな基準に基づいて、キューに入れられたレシピを使用可能なシステムに割り当てる中央スケジューラが含まれています。
これは、レシピの現在のキューを継続的にループし、そのレシピを処理できる利用可能なシステムを探すことによって処理されます。このアプローチクエリは、レシピごとにデータベースから更新されたシステムステータス情報を取得するため、スケジューリングパスの実行中に使用可能になるシステムで、キューのさらに後ろにあるタスクが誤って最初のショットを与えられるという競合状態に悩まされます。
たとえば、2つのシステムAとBがあり、レシピ1（システムAが必要）、2（どちらでも実行可能）、3（どちらでも実行可能）があるとします。スケジューリングパスが開始されると、システムAはすでにビジーであるため、レシピ1には使用可能なシステムがなく、引き続きレシピ2を調べて、システムBに割り当てます。バックグラウンドで、システムAは実行中の処理を終了し、次のようにフラグを立てます。データベースで利用可能。スケジューラーは、レシピ3の検討に移り、システムAが使用可能であることを確認し、レシピ3をシステムAに割り当てます。レシピ1に指定されているはずなのに、レシピ3はキューをジャンプしてシステムAを要求します。
私は、スケジューリングロジックを完全に再設計することを伴わない、これに対する短期的な修正を考え出そうとしています（ただし、その面でいくつかの長期的なアイデアも検討しています）。
私が現在持っている最善の解決策は、スケジューリングパスの開始時のデータベースの状態とスケジューラーが行ったシステム可用性状態の変更のキャッシュとして純粋に別のSQLAlchemyセッションを開くことです。このトランザクションは、スケジューリングパスの終了時に中止されます。スケジューリングパス中に、すべての状態変更は通常どおりデータベースに書き込まれますが、キャッシュ接続にも書き込まれる必要があります。
しかし、これは本当に醜いように思われるので、SQLAlchemyでこれを処理する方法について誰かがもっと良いアイデアを持っているかどうか疑問に思っています。