Container processes in a WebSphere® Application Server environment start automatically when a module starts that has the eXtreme Scale XML files included.
Java™ Platform, Enterprise Edition applications have complex class loader rules that greatly complicate loading classes when using a shared WebSphere eXtreme Scale within a Java EE server. A Java EE application is typically a single Enterprise Archive (EAR) file with one or more Enterprise JavaBeans™ (EJB) or Web archive (WAR) modules deployed in it.
WebSphere eXtreme Scale watches for each module start and looks for eXtreme Scale XML files. If WebSphere eXtreme Scale detects that a module starts with the XML files, it registers the application server as an eXtreme Scale container Java virtual machine (JVM) with the catalog service. By registering the containers with the catalog service, the same application can be deployed in different grids and still be treated as a single grid by the catalog service. The catalog service is not concerned with cells, grids or dynamic grids. Everything either is an eXtreme Scale container JVM or is not. A single logical grid can span multiple WebSphere Extended Deployment cells if required.
Applications within the same cell as the containers can connect to these grids by using a ObjectGridManager.connect(null, null) method and then call the getObjectGrid(ccc, "object grid name") method. The connect or getObjectGrid methods might be blocked until the containers have placed the shards, but this blocking is only an issue when the grid is starting.
ClassLoaders
Any plug-ins or objects stored in an eXtreme Scale are loaded on a certain class loader. Two EJB modules in the same EAR can include these objects. The objects are the same but are loaded using different ClassLoaders. If application A stores a Person object in an eXtreme Scale Map that is local to the server, application B receives a ClassCastException if it tries to read that object. This exception occurs because application B loaded the Person object on a different class loader.
One approach to resolve this problem is to have a root module contain the necessary plug-ins and objects that are stored in the eXtreme Scale. Each module that uses eXtreme Scale must reference that module for its classes. Another resolution is to place these shared objects in a utility jar that is on a common class loader shared by both modules and applications. The objects can also be placed in the WebSphere classes or lib/ext directory, but this complicates deployment and is not recommended.
EJB modules in an EAR file typically share the same ClassLoader and are not affected by this problem. Each WAR module has its own ClassLoader and is affected by this problem.
Connecting to a grid as a client only
If the catalog.services.cluster property is defined in the cell, node or server custom properties, any module in the EAR file can call the ObjectGridManager.connect (ServerFactory.getServerProperties().getCatalogServiceBootstrap(), null, null) method to get a ClientClusterContext and call the ObjectGridManager.getObjectGrid(ccc, "grid name") method to gain a reference to the eXtreme Scale. If any application objects are stored in Maps, verify that that those objects are present in a common ClassLoader.
Java Platform, Standard Edition clients or clients outside the cell can connect using the bootstrap IIOP port of the catalog service (default in Websphere is the deployment manager) to obtain a ClientClusterContext and then obtain a named eXtreme Scale the usual way.
Entity manager
The entity manager helps because the Tuples are stored in the Maps, not the application objects, so that there are less class loader problems of concern. Plug-ins can be a problem, however. Also note that a client override eXtreme Scale descriptor XML file is always required when connecting to an eXtreme Scale that has entities defined: ObjectGridManager.connect("host:port[,host:port], null, objectGridOverride) or ObjectGridManager.connect(null, objectGridOverride).