Retrieving Entities from In-Memory Cache

If no caching engine is provided, the Infinity Process Platform engine retrieves entities per request using a transaction bound memory cache. Some entities are not expected to be changed very often, but are frequently retrieved. If a caching engine is provided, and the caching switch property is not set to false, these entities are stored and retrieved in cross transaction caches. These include the following entities:

Disabling the Caching Mechanism

To turn off the use of caches, even if a caching engine is detected, add the property Infinity.Engine.Caching to your server-side carnot.properties file and set it to false.

Infinity.Engine.Caching = false

Requirements

The cache engine is not part of the Infinity Process Platform distribution, you have to install your own caching engine. The following caching engines are currently supported by the Infinity Process Platform:

Configuration

The configuration required to connect to the client cache engine is to add the corresponding adapter to the Infinity Process Platform engine classpath, either in your carnot.ear file or in the global application server classpath.

The actual configuration of the cache engine should be performed according to the documentation of the respective caching engines installed in your environment.

Note
Please note that the provider should be transaction aware.

Usage of Caches in the Infinity Process Platform

In case an installed cache engine is present in the client environment, Infinity Process Platform detects it and uses it. If no cache engine is found or the installed cache engine is not supported, only the transaction bound memory cache is used.

In case a cache engine is found, the modification pattern of the cacheable entities is changed, in that all changes will be made not on the object retrieved from the cache, but on a different object, either freshly retrieved from the database or cloned from the cached object. This new object will replace the old one in the cache.

The retrieval of cacheable entities is directed to the respective caches whenever possible.

Example Use Case with Hazelcast on WebSphere 7

The following example demonstrates the usage of Hazelcast on WebSphere 7. Hazelcast is a clustering and scalable data distribution platform. For the second level caching functionality the Infinity Process Platform leverages Hazelcast's distributed Map capabilities. Please refer to http://www.hazelcast.com/product.jsp for detailed information on Hazelcast.

To set up Hazelcast on WebSphere 7:

  1. Copy the hazelcast-1.9.jar to the %WAS7_HOME%/AppServer/lib/ folder ( http://mirrors.ibiblio.org/pub/mirrors/maven2/com/hazelcast/hazelcast/1.9/hazelcast-1.9.jar ).
  2. Deploy the following RAR file: hazelcast-ra-was7-1.9.rar, (You also find this file under <Infinity Installation>/examples/hazelcast.)
    1. Resources Adapters > Resources adapters > Install RAR
      1. Choose the RAR, accept all defaults.
    2. Resource Adapters > J2C connection factories > New �
      1. Choose HazelcastRA as provider.
      2. Enter HazelcastCF for both Name and JNDI name.
      3. Click Apply.
      4. Go to Connection Pool Properties.
      5. Adjust Maximum/Minimum connections to 50/10.
      6. Click OK.
    3. Save the following hazelcast.xml file: hazelcast.xml.
    4. Navigate to Servers > Server Types > Websphere application servers > <your server> > Java and Process Management > Process Definition:
      1. Navigate to Java Virtual Machine > Custom properties.
      2. Add a new property
        1. Name: hazelcast.config
        2. Value: <path to hazelcast.xml>
      3. Optionally another property
        1. Name: hazelcast.config.print
        2. Value: true
    5. Now Save to Master Configuration.
    6. Restart the server.
  3. Navigate to Servers > Server types > WebSphere application servers > <your server>.
    1. Navigate to Container Services > Transaction Service.
    2. Ensure Accept heuristic hazard is selected.
  4. Add the following entries to your carnot.properties:
    Infinity.Engine.Caching = true
    
    Infinity.Engine.Caching.CacheFactory = com.infinity.bpm.rt.integration.cache.hazelcast.HazelcastCacheFactory
    
    Infinity.Engine.Caching.Hazelcast.TxMode = rw
    Infinity.Engine.Caching.Hazelcast.ConnectionFactoryJndiName = HazelcastCF
    Infinity.Engine.Caching.Hazelcast.GlobalCacheName = ipp-2nd-level-cache
        
  5. Copy the jsr107cache-1.1.jar into your EAR file ( http://mirrors.ibiblio.org/pub/mirrors/maven2/net/sf/jsr107cache/jsr107cache/1.1/jsr107cache-1.1.jar):
    1. Inside the carnot-engine.jar for the EAR, append jsr107cache-1.1.jar to the already existing classpath: header for MANIFEST.MF.
  6. Redeploy the EAR.
  7. Optionally: deploy the Hazelcast Monitor Web Application
    1. Extract the hazelcast-monitor-1.9.war from the Hazelcast distribution ( http://www.hazelcast.com/files/hazelcast-1.9.zip).
    2. Deploy it to WebSphere, essentially only the context root might need adjustment.
    3. Start the application after deployment.
    4. Point your browser to the context root.
    5. Just press Add Cluster, accepting the defaults.
    6. Click on Maps > ipp-2nd-level-cache to inspect the cache.

The engine now uses Hazelcast as second level cache provider. This can be monitored as cache size and Hit Rate will change after logging into the Infinity Process Platform portal, for example.

The cache is configured to remove cached entries after at most 60 seconds for the time being. This is why Infinity Process Platform will eventually hit the database again to repopulate the cache. The time to live can be adjusted in the hazelcast.xml configuration file (<time-to-live-seconds>).

Please note that with this setup there will be only one node. Hazelcast either detects or is explicitly told about additional node members. For details on this issue please refer to the Hazelcast documentation or the hazelcast.xml file.