See the WebSphere eXtreme Scale Wiki for links to eXtreme Scale Version 7.0 documentation.
If you log in
with your developerWorks ID, you can leave comments and feedback for the development team.
WebSphere Extended Deployment Data Grid has the ObjectGrid runtime embedded in it. Java 2 Platform Enterprise Edition (J2EE) applications have complex class loader rules that greatly complicate loading classes when using a shared ObjectGrid within a J2EE server. A J2EE application is typically a single Enterprise Archive (EAR) file with one or more Enterprise JavaBeans (EJB) or Web archive (WAR) modules deployed in it. For a module to use ObjectGrid, it must include ObjectGrid XML files in the META-INF folder. ObjectGrid watches each module start and looks for ObjectGrid XML files. If it detects that a module starts with the XML files, it registers the application server as an ObjectGrid container JVM with the catalog service, which means that the same application can be deployed in different clusters and still be treated as a single grid by the catalog service. The catalog service is not concerned with cells, clusters or dynamic clusters. Everything either is an ObjectGrid container JVM or is not. A single logical grid can span multiple WebSphere Extended Deployment cells if required.
ObjectGrid detects the presence of objectGrid.xml and objectGridDeployment.xml files in the META-INF folder of EJB and WEB modules when they start. If just an objectGrid.xml is found then it's assumed it is a client, otherwise, it's assumed this JVM will act as a container for the grid defined in the objectGridDeployment.xml file. The container will start automatically when the module is started. The catalog service will start to place partition primaries and replicas (shards) as soon as possible. This is usually immediately unless you defined a numInitialContainers attribute in the objectGridDeployment.xml file. If you defined that attribute then placement starts when that number of containers has started.
Applications within the same cell as the containers should connect to these grids simply using a ObjectGridManager.connect(null, null) method and then call the getObjectGrid(ccc, "object grid name") method. The connect or getObjectGrid may block until the containers have placed the shards but this is only an issue when the grid is starting.
Catalog service in WebSphere Extended Deployment Version 6.1
The catalog service is started automatically within the deployment manager process used by WebSphere Extended Deployment.
ObjectGrid XML files
An EJB module or WAR module using ObjectGrid must have ObjectGrid XML files in its META-INF directory.
The ObjectGrid XML files include:
The ObjectGrid runtime detects these files, then contacts the catalog service to inform it that another container is available to host shards for that ObjectGrid.
 | Important
You must use the correct names for these xml files. They are case sensitive. If they are not present then the container will not start. You can check the systemout.log file for messages indicating that shards are being placed to double check. |
Static ObjectGrid Cluster Topology in WebSphere Extended Deployment Version 6.1
When using the static ObjectGrid server configuration where the servers are defined in an ObjectGrid cluster xml file, the ObjectGrid runtime also detects file names in your application's META-INF directory. The case sensitive names for these files are objectGrid.xml and objectGridCluster.xml. The name of the WebSphere application server must match one of the server names in the objectGridCluster.xml, but the cluster name does not need to match. The server name should be unqualified and not include the cell and node names.
If the ObjectGrid runtime finds a match for one of the server names in the objectGridCluster.xml for the current server, it will start up the ObjectGrid server runtime.
ClassLoaders
Any plug-ins or objects stored in an ObjectGrid 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 ObjectGrid 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 plugins and objects that are stored in the ObjectGrid. Each module that uses ObjectGrid 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 ObjectGridManager.connect(ServerFactory.getServerProperties().getCatalogServiceBootstrap(), null, null) to get a ClientConnectContext and call ObjectGridManager.getObjectGrid(ccc, "grid name") to gain a reference to the ObjectGrid. If any application objects are stored in Maps, make sure that those objects are present in a common ClassLoader.
J2SE 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 ClientConnectContext and then obtain a named ObjectGrid the usual way.
EntityManager
The EntityManager 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 ObjectGrid descriptor XML file is always required when connecting to an ObjectGrid that has entities defined:
ObjectGridManager.connect("host:port[,host:port], null, objectGridOverride) or ObjectGridManager.connect(null, objectGridOverride).
© Copyright IBM Corporation 2007,2009. All Rights Reserved.
