Multi-Tenant Seam + JPA Aplicação

votos
3

Eu trabalho em uma costura existente 2.2.0 + JPA (Hibernate 3.3.1) aplicativo que precisa ser convertido para um ambiente de 'banco de dados único por cliente', onde cada esquema de banco de dados é o mesmo. O aplicativo é executado em Glassfish, usa IceFaces, e tem várias páginas que utilizam Conversations. Ele também usa um único EJB para autenticação. Infelizmente, a decisão de dividir clientes fora em suas próprias bases de dados está fora do meu controle.

Como prova de conceito, já fiz a aplicação consciente de vários bancos de dados, movendo a gestão de EntityManagerFactory (s) e DataSource (s) para o aplicativo usando abstrações Primavera JPA, transacções locais de recursos e ThreadLocal para obter informações de contexto. Por exemplo, cada vez que um usuário faz logon em um novo EntityManagerFactory é inicializado usando uma nova fonte de dados que se comunica com seu banco de dados se ele já não foi inicializado. Isso está funcionando bem em um ambiente de teste com um punhado de bancos de dados.

A minha pergunta é, será esta escala abordagem para centenas de bancos de dados? Espero para adicionar servidores de aplicativos para um balanceador de carga para lidar com carga adicional, mas a sobrecarga de cache de primeiro nível Hibernate / JPA e / ou gerenciamento de contexto Seam (aka, o consumo de memória) requerem significativamente mais servidores para escala em comparação com uma típica carregar uma aplicação equilibrada? Se assim for, isso pode ser atenuado através da atribuição de servidores com muita memória RAM e / ou um grande cache distribuído?

Qualquer visão seria muito apreciada.

Publicado 16/03/2011 em 21:13
fonte usuário
Em outras línguas...                            


1 respostas

votos
1

Eu trabalhei em um aplicativo com essa abordagem e eu o que eu posso salientar é:

  • Fonte de dados e gestão EntityManagerFactory é a parte mais difícil. No entanto, parece que você fez isso já no ambiente de teste. verifique se você fez as coisas direito em relação ao Seam Managed Entity Manager.
  • Sua aplicação não escala bem em centenas de bancos de dados, porque você tem um aumento linear do consumo de memória para cada banco de dados. Na verdade, para cada banco de dados que você está indo ter diferentes instâncias EntityManagerFactory(Hibernate SessionFactory) cada que requerem uma quantidade considerável de Ram.
  • Cuidado com os possíveis problemas se você configurar o Hibernate cache de segundo nível. Uma vez que todos SessionFactories são criados a partir do mesmo modelo de dados os nomes região de cache pode colidir. Eu costumava hibernate.cache.region_prefixparâmetro de configuração para fazer esses nomes únicos entre as várias instâncias usando o ID de banco de dados como o prefixo cache.
Respondeu 25/03/2011 em 10:11
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more