0

Tapestry 5.3.3 を使用してアプリケーションのクラスタリングに取り組んでいます。クラスター化は、クラスター内のすべてのノードに HttpSession を複製することによって実現されます。レプリケーションは、HttpSession をシリアル化することによって発生します。コンテナーがセッションをシリアライズしようとすると、org.apache.tapestry5.internal.SelectModelImpl がシリアライズ可能でないため、NotSerializableException がスローされます。Tapestry は、このクラスを ClusteredSessionImpl クラスを介してセッションに追加します。したがって、Tapestry は、関連情報をセッションに保存することで、クラスターにやさしくしたいと考えているようです。この例外を回避する方法について何か考えはありますか?

4

1 に答える 1

1

Tapestry ユーザーのメーリング リストは、いくつかの良い提案を提供してくれました。明らかに、SelectModel をセッションに永続化することは避けるべきです。ここにいくつかの応答があります -

SelectModel を @Persist しているカスタム コードですか? その場合は、代わりに基礎となる Collection を @Persist し、UI で SelectModel を毎回構築できます。特にクラスタ化された環境では、HTTPSession の使用を最小限に抑える必要があることに注意してください。HTTPSession の使用はうまくスケーリングしません。セッションでリストを永続化する必要は本当にありますか? 代わりに、ユーザー ID (またはその他のフィルター パラメーター) をセッションに保存し、サービスから必要になるたびにリストを検索できますか? ルックアップのコストが高いことが後でわかった場合は、サービス レベルでのキャッシングを検討できます。

これを読む必要があります: http://tapestry.apache.org/performance-and-clustering.html

@Persist または @SessionState SelectModel を使用しないでください。それは悪い考えです。Lance が言ったように、どうにかして永続化する必要がある場合は、SelectModel 自体ではなく、SelectModel の作成に使用される List を永続化します。

于 2013-03-01T15:16:04.087 に答える