I am working on an existing Seam 2.2.0 + JPA application (Hibernate 3.3.1), which needs to be converted to a “one database per client” environment, where each database schema is the same. The app runs on Glassfish, uses IceFaces, and has several pages that use conversations. It also uses one EJB for authentication. Unfortunately, the decision to split clients into their own databases is beyond my control.
As a proof of concept, I already made the application aware of several databases by moving the EntityManagerFactory and DataSource (s) controls to the application using Spring abbreviations JPA, local resource transactions and ThreadLocal for contextual information. For example, each time a user registers with a new EntityManagerFactory, it is initialized using a new DataSource, which contacts its database if it has not been initialized yet. This works well in a test environment with multiple databases.
My question is: will this approach scale to hundreds of databases? I expect to add application servers to the load balancer to handle the extra load, but the overhead of managing the Hibernate / JPA level 1 cache and / or seam contour management (aka, memory consumption) requires a significantly larger number of servers to scale compared to a typical load balanced attachment? If so, can this be mitigated by distributing servers with a lot of RAM and / or a large distributed cache?
Any understanding would be greatly appreciated.
source
share