古典的なエンタープライズアプリケーションの 'synchronized'キーワードは疑わしいですか？

Question

私は古典的なエンタープライズアプリケーションについて話しています。通常、何らかの種類のアプリケーションサーバーまたはコンテナでホストされます。プレゼンテーション/ UIとリレーショナルストレージだけでなく、エンティティ、サービス、エンターテインメントなど。

このようなアプリケーションで​​というキーワード（方法またはブロックのいずれか）が表示されると、私は非常に疑わしい結果になります。 私の意見では、これは、基本的なアーキテクチャの概念（ドメインモデルが複数のクライアント間で共有されていないなど）を理解していないか、アーキテクチャーが実際には非常に悪いというサインをさらに悪化させる兆候です。

ここで私の考え方を分かち合いますか？あるいは私は完全にオフトラックですか？ クラシックエンタープライズアプリケーションで実際に同期が必要なユースケースはありますか？

Answer 1

私はビジネスロジックコードについて同意しますが、エンタープライズアプリケーションでは技術コードもあり、時には共有の「技術的」状態のための同期が必要になることがあります。これにはsynchronizedキーワードを使用することができます。 （原子変数をリレーすることもできますし、DBシーケンスのようなアプリケーションの外で技術状態を共有することもできます）

シーケンス内に穴がない連続した請求番号を作成するには、いくつかの状態を共有する方法、および同期する方法を...

Answer 2

私はあなたに同意します。

スレッドセーフなコンポーネントを設計する際に同期が重要だと思いますが、「ビジネスロジック」コードでは通常は必要ありません。

共有状態を導入することで、パフォーマンスを向上させることができますが、将来的にはアプリケーションのスケーラビリティが低下します。

コンカレント・デザインが必要な場合は、アプリケーション・サーバーなどを使用して、アプリケーション開発者に透過的に処理できます。