Java静的同期とBlockingQueueの実装

Question

サーブレット（resteasy + Hibernate）を使用して予定キューを実装しようとしています。 私の予定コントローラは以下の通りです（もちろん簡略化されています）。

public class AppoController{ 

public synchronized static int createAppoinment(AppObj app){ 
    //get last app no 
    //insert new app with no+1 
    //return new app no 
} 
} 

現在のところ、この方法は問題ありません。しかし、私はBlockingQueueの実装について正しい方法のように見えたのですか？微細加工の

定義：私は、静的な同期を使用する場合
私は、静的な同期を使用して、一度複数の予定で複数の要求を送信いけない場合が持っている同じ任命何
は けど、予定は正しい順序で作成されていない

私はここで任意のスレッドを使用しないでくださいが、私はtomcatは自分のスレッドを使用してユーザーからのHTTPリクエストを処理すると仮定します。 これはマルチスレッドアプリケーションですか？

私はここ数日のためにそれをGoogleで検索しているが、私が得た最も近いiがある明確にするために必要なものJava/Android: Synchronized vs Queue implementation

です。
- これは正しい方法ですか？
- 私のシナリオでは、同期化された静的対BlockingQueueの実装の賛否両論は何ですか？

あなたが関連していると思われるその他の入力も歓迎します。ありがとう。

Answer 1

あなたの実装は機能します。 synchronizedメソッドは、いつでも1つのスレッドでしか実行できません。 Tomcatは複数のスレッドを使用します（詳細は現在の設定に依存し、要求ごとに1つのスレッドを仮定することができます）ので、すべての同時要求は独自のスレッドを取得し、スレッドがメソッドに入ることを許可されるまで、

必要に応じて2つのオプションがあります。

1. アポイントがデータベースに由来する場合は、データベースまたは休止状態でID生成を処理できるようにします。それは、マルチスレッドの問題を、その種の問題を処理するように設計されたデータベースに移します。
2. アポイントがデータベースから来ておらず、アポイントオブジェクトのユニークな識別子が必要な場合は、UUIDを使用します。

実際にキューを使用するのは、http要求から予定の作成を移動する場合にのみ意味があります。例えば。要求が夜間バッチジョブまたは専用ワーカースレッドプールのように終了した後に予定を作成した場合。しかし、これは、予定を作成するのが高価な操作である場合にのみ意味をなさないでしょう。

別のトピックでは、このメソッドが静的である必要があるかどうかを確認する必要があります。