トランザクションのライフサイクルで特定のイベントを生成するシステムがあります。毎回私はDBの行を更新し、websocketを介してUIイベントを送信する必要があります。Akkaの代わりにタスクを順番に処理する
アクターにイベント処理（DBとUI）を実装することで、ロックの問題を避けることができます。マイナーな遅延もありますので、これを順番に処理することで大幅に簡素化されます。
Scalaでこれを処理する別の方法は何でしょうか？この場合、俳優は不当だと思いますか？ このオプションを削除するには、より適切なメカニズムを見たいと思いますが、アクターを「州と同時並行」に使用する必要があるというブログがあります。
最終的に、アクターを使用する主な特長は、変数をカプセル化して競合状態を避けることができることです。
あなたの話をするには、古典的なスレッドを使用するだけです。あなたの（おそらく単純化された）説明では、私はデッドロックの可能性は見当たりません。もう少し組み合わせが可能なようにしたい場合は、一連の非同期タスクでは、ScalaのFutureを使用できます。
これはScalaには当てはまりませんが、GroovyとJavaにはいくつかの並行性モデルを持つ素晴らしいlibがあります。私は自分でDataflow Concurrencyを使って大成功を収めました。軽量で扱いやすいモデルとしてお勧めします。
データフロー同時実行性は、本質的に安全で堅牢な の代替同時実行モデルを提供します。データに重点を置いて、 が実際のプロセスではなくプロセスを流れるようにします。 がデータを操作します。データフローアルゴリズムは、ライブロック、競合条件、デッドロックを扱う の開発者を解放し、決定的であり、したがって100％再現性があります。あなたがデッドロックを受けていない場合、テストで を取得しても、それを稼働させることはできません。
リンクされたGParsライブラリには他のモデルもあります。
他に選択肢がない限り、自分でスレッドを作成することはお勧めしません。
補遺
投稿後、私は、トピックに興味を持った、いくつかの検索を行いました。 Akka has direct support for Dataflow modelのようにも見えます。または少なくともいくつかのバージョンで持っていた。
アクターは、キューを使用して対話するため、ロックの問題を回避します。キューを持つスレッドを使用して、同じレベルの安全性を得ることができます。スレッドに対するアクターの唯一の利点は、アクタがコールスタックのためにメモリを費やさないということです。したがって、同じ量のコアメモリ内のスレッドよりも多くのアクターを持つことができます。アクターモデルの欠点は、単一スレッドで実装できる複雑なアルゴリズムが複数のアクターを必要とするため、アクターの実装が不明瞭に見えることです。