Posts Tagged ‘IBM


Replacing Persistence Caching with In Memory DataGrids

Anyone that designed an enterprise system in Java with non-functional requirements that demanded tight response times faced the challenge of tuning the overall solution. If you are using Hibernate for persistence your first idea is to turn on Hibernate Caching but unfortunately it only Caches loads through Entity Id and sometimes you need to lookup through a secondary unique key. Another solution you might think is turning on Query Cache but as this post points out is more harmful to scalability and latency than you can ever imagine. Although Hibernate Docs and the post referenced above suggest that using @NaturalId annotation and Querying using Criteria API and a specially crafted Restriction through naturalId method would alleviate much of that problem it turns out that updates on related tables hugely undermines the improvements NaturalId queries may bring as this post suggest:

[…] Even though the objects are essentially static, the query cache takes the safe route and says any change to a related table invalidates any and all queries that reference that table. This makes sense, from a generic cache standpoint. […]

Source: Hibernate: Cache Queries the Natural Id Way
Add to this the fact that second level hibernate caches are data caches, not object caches so even on the best case of a cache miss you’d still have the cost of hydrating the object (as it is called on Hibernate terminology).

Object Caching

So, after giving up on all those previous attempts you’ll start considering taking the next obvious path: using/implementing an Object Caching. Have you noticed that I mentioned implementing? Yes, implementing. Now you’ll probably have to take care of the loading process in the case of cache misses, in fact you’ll be using a pattern called Side Caching.
But this can become a tedious code for maintaining and very prone to errors not to mention that implementing asynchronous write-behind won’t be an easy task.

In Memory DataGrids

Fortunately newer solutions marketed as In Memory DataGrids (or IMDG for short) provide an almost automagic way of plugging specially crafted classes that would be responsible for querying the underlying persistent storage on Cache misses, not to mention that they also provide improved partitioning and a great amount of other facilities usually not available on regular caches.
WebSphere eXtreme Scale Loaders and JBoss InfiniSpan CacheStore are examples of such specially crafted extensions for IMDGs. Those APIs also allow for updating the underlying storage (even asynchronously) with the changes that were passed to the in memory cache. One thing still missing (on different extents) on both solutions is the ability of querying the underlying store using a natural key. On eXtreme Scale there is already a framework for loading JPA entities but it lacks the ability of querying the underlying storage by anything different than the Cache Key that in those cases defaults to Entity Id (eXtreme Scale Query API is capable of querying the cache through any eXtreme Scale entity attribute but it only sees the data in memory). InfiniSpan on the other hand as of the 4.0.0 release does not provide anything similar to eXtreme Scale JPALoader or JPAEntityLoader it still sees the database (as on its JDBC Based CacheStore) as means of providing offloading and surviving reloads but never as means of querying data based on application defined format (eg.: application entities). Instead it uses its own format for storing data which limits its capability of loading from application storage in case of cache misses.

Querying IMDGs through Natural Keys

In summary, if you need to query through a natural key, in both cases you’ll need to roll your own Loader/CacheStore. And by querying through a natural key I mean something along the lines of what is described on Bill Burke’s EJB3 book:

The first way to define a primary-key class (and, for that matter, composite keys) is to use the @IdClass annotation. Your bean class
does not use this primary-key class internally, but it does use it to interact with the entity manager when finding a persisted object through
its primary key.
In your bean class, you designate one or more properties that make up your primary key, using the @Id annotation. These properties
must map exactly to properties in the @IdClass.

This way you can query the Cache using something in the lines of:

MyObjectNaturalKey key = new MyObjectNaturalKey("keyField1", "keyField2");
MyObject o = (MyObject) cache.get(key);

And you’ll have the guarantee that if this object exists either already on memory or in JPA EntityManager it’ll be returned.

Implementing a InfiniSpan CacheStore

Infinispan’s CacheStore interface has the following methods:

package org.infinispan.loaders;
public interface CacheStore extends CacheLoader {
   void store(InternalCacheEntry entry) throws CacheLoaderException;
   void fromStream(ObjectInput inputStream) throws CacheLoaderException;
   void toStream(ObjectOutput outputStream) throws CacheLoaderException;
   void clear() throws CacheLoaderException;
   boolean remove(Object key) throws CacheLoaderException;
   void removeAll(Set<Object> keys) throws CacheLoaderException;
   void purgeExpired() throws CacheLoaderException;
   void prepare(List<? extends Modification> modifications, GlobalTransaction tx, boolean isOnePhase) throws CacheLoaderException;
   void commit(GlobalTransaction tx) throws CacheLoaderException;
   void rollback(GlobalTransaction tx);
   public CacheStoreConfig getCacheStoreConfig();

If you need further explanation of what each method does, see its JavaDoc. InfiniSpan team suggests having a look on DummyInMemoryCacheStore in order to have a general idea of how should a CacheStore be implemented but still I have the feeling it misses an explanation of how InternalCacheEntries should be instantiated and in fact there is a factory class for it.
At last, if you need further information JBoss InfiniSpan Wiki has an overview of the builtin CacheStore classes.

Implementing an eXtreme Scale Loader

eXtreme Scale has plenty information on how to write a Loader as well. InfoCenter has two important pages: the first one presents a general overview on how to write a loader, the second one presents one important concept of eXtreme Scale: its tuples. If you implement a Loader that stores its data based on tuples you are free from having to have the stored classes (in case of custom application classes) in the same classloader as the container process.
WebSphere eXtreme Scale Wiki has a page dedicated to explaining how to write a Loader which presents the signature of a class that implements the Loader interface:

public interface Loader {
    static final SpecialValue KEY_NOT_FOUND;
    List get(TxID txid, List keyList, boolean forUpdate) throws LoaderException;
    void batchUpdate(TxID txid, LogSequence sequence) throws LoaderException, OptimisticCollisionException;
    void preloadMap(Session session, BackingMap backingMap) throws LoaderException;

Apart from the Wiki there’s a post on Billy New Port’s DevWebSphere blog
that has the source code available for what he calls the PureQuery Loader for eXtreme Scale. It is a loader capable of loading POJOs from SQL queries.
Finally if you need a starting guide for eXtreme Scale, have a look at ObjectGrid programming model guide and samples that although slighlty old is still a good starting guide for WebSphere eXtreme Scale.
Lastly I’d like to say that Packt Publishing book on eXtreme Scale is also a good reference for it.


WebSphere eXtreme Scale 6 book

As already stated I’ve been invited to review WebSphere eXtreme Scale book from Packt Publishing. The book is an excellent choice for anyone interested in adopting WebSphere eXtreme Scale in a solution.

WebSphere eXtreme Scale

WebSphere eXtreme Scale Book

The book starts on chapter one with basic concepts about a data grid and ends up with a hello world like application.

On chapter two it starts to take a deeper dive into WebSphere eXtreme Scale concepts. The first one explored is the ObjectMap API which is composed by the ObjectMap and the BackingMap objects.

Chapter three is the one that specially took my attention since it presented me a feature I had no clue eXtreme Scale had: a JPA like implementation. This is one of the things that makes eXtreme Scale such a nice tool. By now you will probably be thinking: “but what is the difference of having this and eXtreme Scale acting as an ORM cache?”. In fact there’s a great deal of differences – first one: on an ORM solution you’re caching data that when “hydrated” (as Hibernate calls it – this article explains something about hibernate 2nd level cache) becomes objects, so, you still have the time lapse and the memory losses derived from hydrating objects on each request. Another major advantage is that ORM caches are usually invalidated upon some update scenarios which leads to reload of data.

Chapter four covers how to integrate a data grid with a database store. As the book states you’d need to integrate with a database backend to provide a richer and wider set of tools for report generation, to integrate with legacy application that still interact with database, etc.

Chapter five is dedicated to handling increased load. If you thought: “Do I still need to care about load increase?” the answer is “YES! For Sure!”. All and every software needs to be proper configured for increased load, by no means eXtreme Scale would be an exception and this chapter covers important topics of performing planning  for increased load.

Chapter six is devoted to keeping data available, so now it focus on replication and other important points.

Chapter seven (which is also freely available online) presents a rather different pattern of performing tasks in a distributed application – pushing the operation instead of pulling the data.

Chapter eight is dedicated to present some common patterns when using a data grid.

Chapter nine covers some facilities for Spring integration.

And finally chapter ten covers a complete example of a project that is built open eXtreme Scale.

One thing I’d like to see on the books next edition is the ability of replacing WebSphere’s Application Server DynaCache with an eXtreme Scale cache implementation. But it is no surprise for me that this was missing on book since they (the book and this feature) were released almost at the same time, invalidating any possibility of this being covered on the book.

In summary: this is a book I really recommend for anyone interested in picking a data grid solution for Java. It is also more recommended if you are already inclined to use an IBM solution and stick with eXtreme Scale.


WebSphere eXtreme Scale 6 book review

Anyone designing a high performance transaction processing system has already needed at least a caching solution for increasing response time on frequently used data. But sometimes these data might become bigger than usual, those are times when you need a sofisticate

WebSphere eXtreme Scale

WebSphere eXtreme Scale Book

solution, something that can automatically fetch data from a slower storage, offload when not necessary, split its contents between various nodes, …

If you require something like this then you’ll notice that you need a DataGrid solution.

By now you’ll be asking yourself why I am on that subject? Recently I’ve been kindly invited to review a book about IBM WebSphere eXtreme Scale from Packt Publishing.

Apart from this, I work on a project where we were already evaluating WebSphere eXtreme Scale as a replacement for WebSphere DynaCache.

If you are in a hurry and want to have a sneak peak on the book contents, take a look at the sample chapter (Chapter 7: “The DataGrid API”) available for free on Packt Publishing website.


Accessing a HMC through a SSH tunnel

For sysadmins this might be a rather easy task, but as a HMC end-user I had to search a little bit.
If you never used an IBM server you might be wondering what is an HMC. At first it seems like a notebook in a blade format as you can see on the picture below:

But apart from its similarity to a fancy notebook, its purpose is to allow administration of IBM LPARs (or DLPARs after Power6 arrival).
There you can boot, shutdown, change CPUs and memory for LPARs, etc.
Apart from allowing the administration in loco, it provides a Java based application that can be installed either through a Java Web Start launcher or using an MSI installer.
I’ll try to explain the steps involved in running it using the JNLP Java Web Start launcher.

Setup SSH tunnel and Download JNLP

Open the SSH connection between you and any host on the same network as your HMC (this can even be the HMC itself) and tunnel the following ports from your machine to HMC’s IP.

  • 30000 up to 30009
  • 9090
  • 9960
  • 8443
  • 443
  • 80

Sincerely, I did not check if, strictly speaking, all the ports are necessary but feel free to test them and leave  a comment. These ports were the result of a few searches over the internet.

After setting up the tunnel, point your preferred browser to http://localhost and download the JNLP file at the following link:

HMC html page

HMC html page

I had to edit the codebase property of the JNLP file, but I guess it wont be necessary as I still had to edit the hosts file and add an alias for the machine name (eg.:  You’ll end up having codebase as follows:


Edit hosts file

The next step is to edit your hosts file so it will have an extra alias pointing to Copy the host name from the original value of the codebase property.
Then launch the JNLP file with Java Web Start. If you have the mime type correctly associated at your operating system, double click the file and wait for its launch. Sometimes it may complain at the first connection attempt, retry it and it’ll connect successfully. I guess I might still be missing some ports from the 30000~30009 range, since my first attempt was using ports from 30001~30009 and it always complained at the first attempt.


First impressions of IBM WebSphere MQ Low Latency Messaging

IBM has a rather new platform for messaging. It is called WebSphere MQ Low Latency Messaging (aka WebSphere MQ LLM). It was released on the fourth quarter of 2007 and sincerely it hasn’t much similarities with the well known WebSphere MQ (former MQ Series).

First of all, after installing it you will probably notice that there isn’t a service for starting up. Soon you notice that it is rather a library that provides messaging services. Actually, it is a native library (currently [v2.1] only available for Linux x86, Windows x86 and Solaris Sparc) that comes already with JNI bindings.

To make things even harder, there isn’t much documentation available (and it seems like IBM is still organizing its docs online).

But, IBM claims that it has shown impressive numbers on its benchmarks:

WebSphere MQ Low Latency Messaging has demonstrated very high throughput, one-to-many multicast messaging, which can deliver approximately one million 120-byte messages per second on Ethernet, close to three million 120-byte messages per second on InfiniBand, and more than 8 million smaller messages per second, all on common x86 servers. Testing has also measured very low latency of 30 microseconds for 120 byte messages delivered at 10,000 messages per second on InfiniBand or 61 microseconds on Ethernet (1)

Source: IBM press release

In its Java version, the main classes that you’ll interact when using WMQ LLM are:

  • RUMInstance (available through RUMFactory)
  • RMMInstance

For instance, RUM stands for Reliable Unicast Messaging and RMM stands for Reliable Multicast Messaging. As you can guess, RUM is used for Queue styled messaging and RMM for Topic styled messaging.

One of its drawbacks is that it still lacks a JMS based Resource Adapter but nothing denies you from rolling your own if you can’t wait for an official adapter from IBM.

I am planning to do some benchmarking against a regular MQ integrated application. As soon as I have the results I’ll post them over here.


Blog Stats

  • 375,197 hits since aug'08

%d bloggers like this: