Os servidores de contêiner em um ambiente do WebSphere Application Server iniciam automaticamente quando é iniciado um módulo que possui os arquivos XML do eXtreme Scale.
Os aplicativos Java Platform, Enterprise Edition possuem regras de carregador de classe complexas que complicam muito o carregamento das classes quando uma grade de dados compartilhados é usada dentro de um servidor Java EE. Um aplicativo do Java EE normalmente é um arquivo Archive Corporativo (EAR). O arquivo EAR contém um ou mais módulos do Enterprise JavaBeans (EJB) ou archive web (WAR) implementados.
O WebSphere eXtreme Scale procura cada início de módulo e consulta arquivos XML do eXtreme Scale. Se o serviço de catálogo detectar que um módulo inicia com os arquivos XML, o servidor de aplicativos será registrado como um servidor de contêiner Java Virtual Machine (JVM). Ao registrar os servidores de contêiner com o serviço de catálogo, o mesmo aplicativo pode ser implementado em grades de dados de dados diferentes, mas não pode ser usado como uma grade de dados única pelo serviço de catálogo. O serviço de catálogo não é referente às células, grades ou grades dinâmicas. Uma única grade de dados pode se propagar por diversas células, se necessário.
Aplicativos dentro da mesma célula que os contêineres podem se conectar a estas grades de dados utilizando um método ObjectGridManager.connect(null, null) e, em seguida, chama o método getObjectGrid(ccc, " object grid name "). Os métodos connect ou getObjectGrid podem ser bloqueados até que os contêineres tenham colocado os shards, mas este bloqueio é um problema apenas quando a grade de dados está iniciando.
ClassLoaders
Quaisquer plug-ins ou objetos armazenados em um eXtreme Scale são carregados em um determinado utilitário de carga de classes. Dois módulos EJB no mesmo EAR podem incluir esses objetos. Os objetos são o mesmos, porém são carregados usando ClassLoaders diferentes. Se o aplicativo A armazena um objeto Person em um mapa que é local para o servidor, o aplicativo B recebe um ClassCastException se ele tentar ler esse objeto. Esta exceção ocorre porque o aplicativo B carregou o objeto Person em um utilitário de carga de classe diferente.
Uma abordagem para resolver este problema é ter um módulo raiz que contém os plug-ins e objetos necessários que estão armazenados no eXtreme Scale. Cada módulo que utiliza o eXtreme Scale deve referenciar tal módulo para suas classes. Outra resolução é colocar este objetos compartilhados em um arquivo JAR do utilitário que está em um carregador de classe comum compartilhado por ambos os módulos e aplicativos. Os objetos também podem ser colocados nas classes do WebSphere ou no diretório lib/ext, no entanto, esse posicionamento complica a implementação.
Os módulos EJB em um arquivo EAR normalmente compartilham o mesmo ClassLoader e não são afetados por este problema. Cada módulo WAR possui seu próprio ClassLoader e é afetado por este problema.
Conectando-se apenas ao cliente da grade de dados
Se a propriedade catalog.services.cluster for definida na célula, nas propriedades customizadas de nó ou servidor, qualquer módulo no arquivo EAR poderá chamar o método ObjectGridManager.connect (ServerFactory.getServerProperties().getCatalogServiceBootstrap(), null, null) para obter um ClientClusterContext. O módulo pode também chamar o método ObjectGridManager.getObjectGrid(ccc, "grid name") para obter uma referência para a grade de dados. Se qualquer objeto do aplicativo for armazenado em Mapas, verifique se esses objetos estão presentes em um ClassLoader comum.
Os clientes Java ou clientes fora da célula podem conectar-se usando a porta IIOP de autoinicialização do serviço de catálogo. No WebSphere Application Server, o gerenciador de implementação hospeda o serviço de catálogo por padrão. O cliente pode então obter um ClientClusterContext e a grade de dados nomeada.
Entity Manager
Com o gerenciador de entidades, as tuplas são armazenadas nos mapas em vez de nos objetos de aplicativos, resultando em menos problemas do carregador de classe. Entretanto, os plug-ins podem ser um problema. Observe também que o arquivo descritor XML do ObjectGrid de substituição do cliente sempre é necessário ao se conectar a uma grade de dados que possui entidades definidas: ObjectGridManager.connect("host:port[,host:port], null, objectGridOverride) ou ObjectGridManager.connect(null, objectGridOverride).