Does ObjectGrid need WebSphere Application Server for its operation? NO

I get emails from customers saying they understand that ObjectGrid (WebSphere Extreme Scale) requires WebSphere Application Server for high availability because they heard it uses the HAManager and that other competitive products are peer to peer out of the box. This is just not true. ObjectGrid in no way requires any piece of our application server to be installed to perform any core capability. Everything is inside that one jar (objectgrid.jar) that ships with the product when you want to use it with straight J2SE or Tomcat.

ObjectGrid offers full peer to peer fault tolerance, high availability when used in a J2SE environment. The product is called WebSphere Extreme Scale purely because of branding within the company. It in no way implies that our application server is required for ObjectGrid to perform any of its capabilities. We have done work to integrate it with our application server pretty tightly but this work in no way means that it is any less capable when running in straight J2SE or competitive platforms like Tomcat etc.

Why would someone use WebSphere Application Server (ND) with ObjectGrid installed on top? Lots of reasons. The customers operations staff may be familiar with the application server and would naturally want to manage ObjectGrid using the same skill set. If this is what you want then you can package your ObjectGrid application into a conventional WAR or EJB module and deploy it to an ND cell and then manage it just like any other JavaEE application using the same skill set. They can then use PMI to monitor metrics from ObjectGrid using the ND console. ObjectGrid can integrate with WebSphere security which makes it easier to manage if you're already a WebSphere customer. If you're using smaller grids (<50 JVMs) then this is a very attractive approach.

If a customer wants extremely high performance HTTP session replication then we recommend running ObjectGrid within WebSphere ND. But, we'd recommend the same thing to a Tomcat customer looking for the same high performance session replication for their Tomcat application. The same ObjectGrid code is working in both.

Why would you use ObjectGrid in J2SE mode in a WebSphere ND shop? If you want a Java 6 virtual machine for hosting the ObjectGrid data then this makes using ObjectGrid in a J2SE mode mandatory if you are using any version of WebSphere below 7.0 (which includes Java 6). If the grid needs to scale to more than around 50 JVMs then I'd recommend running it in a J2SE environment purely because it's easier to manage, ObjectGrid scales to well over a thousand JVMs and around 2 TB of data (32 bit JVMs) with no administration necessary as you scale it up, just start more JVMs. If 64 bit JVMs are used then more data can be stored. The applications running in the application server can connect to the grid over the network in this mode.

If anyone has questions then please comment here or post a thread on our forum.

Comments

[Ara]

Billy,

I've started evaluating ObjectGrid for an application which will be deployed on Z/OS. AFAIK ObjectGrid is not supported in Server mode on zos. Does that mean I won't have a cluster of ObjectGrids? Core mode is supprtoed which I think means it's per-jvm/no-clustering/no-jvm.

So what's your recommendation for deployment of clustered ObjectGrid instances in a set of jvms on a Z/OS mainframe?

Does this post mean I can workaround the lack of server mode support on z/os by simply pretending the websphere jvm is a j2se jvm and just configure it that way, i.e. not using the server features? Will I hit any roadblocks if I go that route?

Ara.

[Billy Newport]

Core mode means without Spring or things like that. Clustering works without any other jars. Z/OS is always interesting. Due to the architecture of WebSphere Z/OS, I'd only recommend running the ObjectGrid client within a JavaEE application deployed on WebSphere Z/OS. The server portion of the grid can be run in one of three ways.

1) A set of JVMs running ObjectGrid started with JCL scripts. You can start as many JVMs as you need to run the 'grid' servers in this fashion. Just make sure the JCL starts the JVMs with the right billing codes. The JavaEE clients can then bootstrap to these grid JVMs and interact with them. We'd be storing data only in the JCL managed JVMs.

2) zLinux. You can clearly run the ObjectGrid servers within zLinux LPARs also.

3) Distributed. Finally, if you can't do 1 or 2 then you can always run the grid on Power or x86 type boxes.

[Ara]

Another question, this one a rather fundamental one: what's your opinion on in-memory databases such as IBM SolidDB vs in-memory data grids such as ObjectGrid? What are the sweet spots for each?

Ara.

[Billy]

See here

http://www.devwebsphere.com/devwebsphere/2008/05/websphere-extre.html

[Rodolfo]

Hi Billy

I have been wondering about how ObjectGrid could help me on a Hibernate based project.

My first thought was to delegate all our transactions to Objectgrid then asynchronously persist these objects back to the database.

But then I realized I should query my entities from the ObjectGrid instead of from database, since ObjectGrid would hold the last consistent version of the entities, while database would contain staled data until the ObjectGrid loader finishes his job of persist these entities back to database.

So, my question is: how do usually ObjectGrid based applications deal with this ? It is better to have available memory in order to have ObjectGrid holding all data from database ?

What about using the new Hibernate L2 cache loader ? Does this give us a transparent query semantic with consistent (transactional) data ?

Thanks,
Rodolfo