ほとんどのJava Webアプリケーションフレームワークでは、セッション状態を保存するためにサーバー側のセッションオブジェクトが使用されます。これはスケーリングを複雑にするので、私は、シェアードナッシングアーキテクチャを実装しているフレームワークを見ています。 Play! FrameworkおよびApache Click。このリストに追加する他のフレームワークは何ですか？Shared-nothing Java Webアプリケーションフレームワーク
GWTフレームワーク - あなたは（メモリシングルトンや検証のためにデータベースに格納することができる）のみの許可トークンを送信しますが、クライアント側とサーバーに必要なすべてを保存できるので、あなたは、完全なAJAXアプリケーションを作成。
クライアント側のjavascriptソリューションで、同じことができます。クライアント側では、Spring MVCをビジネスメソッドの実装に使用し、RESTチャネル（JSONのデータ転送プロトコルが好ましいオプションです）経由で許可することができます。
MVCフレームワークを使用し、セッションを使用しないでください。死んだのは簡単です：彼らの大部分はセッションを自分で使用しません。セッションに何かを入れるかどうかはあなたが決定します。
プレーフレームワークは、ステートレスな原則で設計されているため、必要なものすべてを提供する必要があります。前述のように、他のフレームワークはトリックを行うことができますが、再生は完全なスタックであり、急速な開発に対応しています（おそらく、Java用のRuby on Railsに相当します）。 ユーザーの認証と承認を使用して、本格的なWebアプリケーションを簡単かつ迅速に開発できます。チュートリアルを進めることを強く勧めます。 Java開発はそれほど生産的で楽しくはありませんでした。
Restlet（2.1）にはCookieAuthenticatorがあり、サーバーサイドセッションに依存せずに認証を処理するため、リストに追加できる別のフレームワークです。
まあ...どのフレームワークでも同じテクニックを使うことができますが、ビュー層で使用されるELに「Cache」のようなルックアップを組み込むことができるものもあります。 –
ここでは複数の誤りがあります：1）ほとんどの場合、したくない場合は「セッション」を使用する必要はありません。2）セッションを使用しているだけで、必ずしもあなたのWebアプリケーションを作成するわけではありません"スケーラブル"。 「スケーラビリティ」はアーキテクチャによって異なります。アーキテクチャは要件によって異なります。 *馬の前にカートを置いてはいけません。*早めの最適化に気をつけないでください。（私たちが知っているように、 "すべての悪の根源"です）; IMHO ... – paulsm4
ユーザーがログインできるようにする必要があると述べました。ほとんどのフレームワークでは、サーバー側セッションを使用してこれをサポートしています。これは、マシン間でセッションオブジェクトを複製したり、スティッキセッションを設定したりすることを意味します。 "早期の最適化"ではなく、1台のマシンを超えて拡張できることが条件です。それゆえ、他のすべてが同等であり、多くの州を必要としないフレームワーク（例：Wicket）を使用し、 （暗号化されたクッキーを使用して）クライアント上で必要とされることはより簡単でより適切であるようです。 – ejain