1

Webアプリでは、ページごとにJSFを介して6つのオブジェクト（テーブルDBの行）のビューを表示する必要があります。次のビューに進むには、別のランダムな6つのオブジェクトが表示されます。

そのため、指定された間隔で、たとえば1時間ごとに、@Scheduleジョブを使用してテーブルのすべての行をクエリする@Singletonを作成することを考えていました。getCollection（）メソッドがあります。

次に、すべての訪問者が@SessionScoped CDI Beanを持ち、@ Singletonのコレクションを照会し、それをシャッフルして特定のユーザーにランダムなビューを作成します。

多くの訪問と同様に、getCollection（）メソッドに同時にアクセスする多くのCDIBeanが作成されます。

これは正しい考えですか？この場合、特定の注釈が必要ですか？これを行う他の方法はありますか？

- - -アップデート - -

友人、特にLuiggi Mendozaと話した後、ここでの最良の方法は、Singleonの代わりにEHCACHEなどを使用することであると教えてくれました。そうだと思います。

4

1 に答える 1

5

Webサーバーのクラスターはありますか？その場合、分散キャッシュが必要であるか、データベースを介して状態を更新する必要があります。

それ以外の場合は、Bean内の単純なマップを探します@ApplicationScoped。

私は、大量のデータがほとんど常に同じであるソリューションでJPAを使用しています。複数のTomcatが関係しているため、Bean内の純粋なキャッシュは機能し@ApplicationScopedません。これを修正するために、第2レベルのキャッシュがなく、代わりにデータベースクエリの結果をキャッシュします。つまり、各Tomcatには独自のキャッシュがあります。

ログインごとにタイムスタンプが読み取られ、キャッシュ内のデータが古くない場合はそれが使用されます。それ以外の場合、キャッシュは更新されます。データベーストリガーを使用して変更が発生すると、タイムスタンプが更新されます。

@PrePersist
@PreUpdate
@PreRemove
public void newTimeStamp() {
// save a new timestamp
}

@SingletonはCDI仕様の一部ではないので、使用を控えます。

また、クライアントBeanを保持@RequestScopedし、6つのオブジェクトをでリロードします@PostConstruct。そうすれば、リクエストごとに新しい6を取得できます。

または、それが短命である場合は、おそらく@ViewScoped（myfaces codiが必要）、@ConversationScopedまたは@ViewAccessScoped（myfaces codiが必要）。

于 2013-02-11T16:50:23.283 に答える