データ層でJPAを使用するjboss7上の通常のJavaEEアプリケーションをまとめています。このアプリケーションは、負荷に応じてスケールアップするように作成したいと思います。Web層をスケールアップする方法はかなり明確ですが、より多くのマシンを作成してロードバランサーの背後に配置しますが、データ層のスケールアップはそれほどではありません。
おそらくデータベース（MySQL）をクラスター化できます。それでも、JPAレイヤーはクラスター化されません。理想的には、JPAは、MySQLに裏打ちされた（クラスター化された）メモリキャッシングを使用してスケールアップします。
周りを見回すと、JPAスケーリングに関するすべての情報は3〜4年前のもののようです。人々はehcache、memcached、infinispanについて話します。これがまだ最新かどうかはわかりません。
特にデータ層におけるJavaEEのクラスタリングとスケーリングの最新技術を教えてもらえますか。
さまざまなキャッシング戦略が、JPA / Hibernateをスケーリングする方法です（基本的に、質問で最も人気のあるオプションに名前を付けました）。私の知る限り、この分野では4〜5年以来特別なことは何も起こりませんでした。言及していないもう1つのオプションは、JBossCacheです。したがって、JPA/Hibernateの第2レベルのキャッシュは引き続きこの領域を支配します。
なぜここで進歩がないのですか？私の大げさな推測では、まず、スケーラブルなアプリケーションを必要とする人々は、高性能が必要な領域でJPAとHibernateを無視する傾向があります。通常、人々はSpringFrameworkJDBCTemplateヘルパーとトランザクション管理に身を包んだSQLを使用します。次に、スケーラビリティはこの領域のデータベース機能の問題です。
もう1つの傾向は、No-SQLデータベースを使用することです。いくつか例を挙げると、MongoDB、CouchoDB、Cassandra、Redisなどのソリューションがあります。これらは通常、キーバリューストレージのようなGoogle BigTableであり（これは単純化しすぎていますが、多かれ少なかれそのアプローチの背後にある考え方です）、制限を受け入れると（関係を簡単に管理できなくなるなど）、地獄のように拡張できます。
多くのソリューションがあり、ソリューションの2つの主要なカテゴリは次のとおりです。
EclipseLinkは、一連のデータベースインスタンス間でデータをシャーディングするためのデータパーティショニングをサポートしています。
参照： http： //java-persistence-performance.blogspot.com/2011/05/data-partitioning-scaling-database.html
MySQLクラスターを使用することもできます。
参照： http ：//www.mysql.com/products/cluster/
Oracle TopLink Gridは、分散キャッシュとしてOracleCoherenceと統合するためのEclipseLinkJPAサポートを提供します。
参照： http ：//www.oracle.com/technetwork/middleware/ias/tl-grid-097210.html
EclipseLinkのキャッシュは、キャッシュ調整によるクラスタリングをサポートします。
参照： http ：//wiki.eclipse.org/EclipseLink/Examples/JPA/CacheCoordination