我正在处理一个现有的Seam 2.2.0 + JPA(Hibernate 3.3.1)应用程序,需要将其转换为“每个客户端单个数据库”的环境,其中每个数据库架构相同。该应用程序在Glassfish上运行,使用IceFaces,并且有几个页面利用Conversations。它还使用一个单独的EJB进行身份验证。不幸的是,将客户端拆分到他们自己的数据库中的决定不在我的控制之内。
作为概念验证,我已经通过使用Spring JPA抽象、资源本地事务和ThreadLocal上下文信息,将EntityManagerFactory(ies)和DataSource(s)的管理移到了应用程序中,让应用程序意识到多个数据库。例如,每次用户登录时,如果尚未初始化与其数据库通信的新DataSource,则会初始化一个新的EntityManagerFactory。这在少量数据库的测试环境中运行良好。
我的问题是,这种方法是否适用于数百个数据库?我打算向负载均衡器添加应用程序服务器来处理额外的负载,但是与 typicall 负载平衡应用程序相比,Hibernate/JPA一级缓存和/或Seam上下文管理(即内存消耗)的开销是否需要更多服务器才能扩展?如果是这样,是否可以通过分配具有大量RAM和/或大型分布式缓存的服务器来缓解这种情况?
非常感谢任何见解。
作为概念验证,我已经通过使用Spring JPA抽象、资源本地事务和ThreadLocal上下文信息,将EntityManagerFactory(ies)和DataSource(s)的管理移到了应用程序中,让应用程序意识到多个数据库。例如,每次用户登录时,如果尚未初始化与其数据库通信的新DataSource,则会初始化一个新的EntityManagerFactory。这在少量数据库的测试环境中运行良好。
我的问题是,这种方法是否适用于数百个数据库?我打算向负载均衡器添加应用程序服务器来处理额外的负载,但是与 typicall 负载平衡应用程序相比,Hibernate/JPA一级缓存和/或Seam上下文管理(即内存消耗)的开销是否需要更多服务器才能扩展?如果是这样,是否可以通过分配具有大量RAM和/或大型分布式缓存的服务器来缓解这种情况?
非常感谢任何见解。