Product overview > Transaction processing overview

Distribute transactions

Use Java™ Message Service (JMS) for distributed transaction changes between different tiers or in environments on mixed platforms.

JMS is an ideal protocol for distributed changes between different tiers or in environments on mixed platforms. For example, some applications that use eXtreme Scale might be deployed on IBM WAS Community Edition, Apache Geronimo, or Apache Tomcat, whereas other applications might run on WAS v6.x. JMS is ideal for distributed changes between eXtreme Scale peers in these different environments. The high availability manager message transport is very fast, but can only distribute changes to JVMs that are in a single core group. JMS is slower, but allows larger and more diverse sets of application clients to share an ObjectGrid. JMS is ideal when sharing data in an ObjectGrid between a fat Swing client and an application deployed on Extended Deployment.

The built-in Client Invalidation Mechanism and Peer-to-Peer Replication are examples of JMS-based transactional changes distribution. See Enable the client invalidation mechanism and Configure peer-to-peer replication with JMS for more information.

Implement JMS

JMS is implemented for distributing transaction changes by using a Java object that behaves as an ObjectGridEventListener. This object can propagate the state in the following four ways:

  1. Invalidate: Any entry that is evicted, updated or deleted is removed on all peer JVMs when they receive the message.

  2. Invalidate conditional: The entry is evicted only if the local version is the same or older than the version on the publisher.

  3. Push: Any entry that was evicted, updated, deleted or inserted is added or overwritten on all peer JVMs when they receive the JMS message.

  4. Push conditional: The entry is only updated or added on the receive side if the local entry is less recent than the version that is being published.

Listen for changes for publishing

The plug-in implements the ObjectGridEventListener interface to intercept the transactionEnd event. When eXtreme Scale invokes this method, the plug-in attempts to convert the LogSequence list for each map that is touched by the transaction to a JMS message and then publish it. The plug-in can be configured to publish changes for all maps or a subset of maps. LogSequence objects are processed for the maps that have publishing enabled. The LogSequenceTransformer ObjectGrid class serializes a filtered LogSequence for each map to a stream. After all LogSequences are serialized to the stream, then a JMS ObjectMessage is created and published to a well-known topic.

Listen for JMS messages and apply them to the local ObjectGrid

The same plug-in also starts a thread that spins in a loop, receiving all messages that are published to the well known topic. When a message arrives, it passes the message contents to the LogSequenceTransformer class where it is converted to a set of LogSequence objects. Then, a no-write-through transaction is started. Each LogSequence object is provided to the Session.processLogSequence method, which updates the local Maps with the changes. The processLogSequence method understands the distribution mode. The transaction is committed and the local cache now reflects the changes. For more information about using JMS to distribute transaction changes, see Distribute changes between peer JVMs.

Parent topic:

Availability overview

Parent topic:

Transaction processing overview

Related concepts

High availability

Replicas and shards

Configure zones for replica placement

Multi-master data grid replication topologies

Map sets for replication


CopyMode attribute

Map entry locking

Locking strategies

Single-partition and cross-data-grid transactions

Related tasks

Configure peer-to-peer replication with JMS


Search Tips   |   Advanced Search