Used in: caching-schemes, cachestore-scheme, near-scheme.


A jms-scheme defines a cache which may be accessed from outside a Coherence cluster, via a JMS-based protocol. For additional details see the Coherence*Extend-JMS configuration instructions.


This scheme uses the to instantiate the necessary implementations (stub and proxy) to support Coherence API calls over JMS.

The Coherence*Extend-JMS stub implements both the and interfaces.


The following table describes the elements you can define within the jms-scheme element.

Element Required/Optional Description
<scheme-name> Optional Specifies the scheme's name. The name must be unique within a configuration file.
<scheme-ref> Optional Specifies the name of another scheme to inherit from.
<queue-connection-factory-name> Required Specifies the JNDI name of the JMS QueueConnectionFactory used by Coherence*Extend-JMS.
<topic-connection-factory-name> Required Specifies the JNDI name of the JMS TopicConnectionFactory used by Coherence*Extend-JMS.
<queue-name> Required Specifies the JNDI name of the JMS Queue used by Coherence*Extend-JMS.
<topic-name> Required Specifies the JNDI name of the JMS Topic used by Coherence*Extend-JMS.
<request-timeout> Optional Specifies the maximum amount of time that a Coherence*Extend-JMS stub will wait for a response from a Coherence*Extend-JMS proxy.

The value of this element must be in the following format:


where the first non-digits (from left to right) indicate the unit of time duration:

  • MS or ms (milliseconds)
  • S or s (seconds)
  • M or m (minutes)
  • H or h (hours)
  • D or d (days)

If the value does not contain a unit, a unit of seconds is assumed.

A value of zero implies no timeout.

Default value is zero (no timeout).

Additional notes on configuring Coherence*Extend-JMS caches:

When you are are configuring caches for use with Coherence*Extend-JMS you need to use the cache with the same name, but different configurations on the stub (client) and the proxy (cluster) sides of Coherence*Extend-JMS. One possible way to accomplish this easily using a single cache configuration descriptor file is to use the Command Line Setting Override Feature of the cache configuration descriptor in the cache-mapping element in conjunction with two separate cache-scheme configurations.

For Example, if you configured a Coherence*Extend-JMS and set up the configuration for the Vehicles cache as follows:

            <scheme-name system-property="cache-scheme">distributed</scheme-name>


Then you could use the same cache configuration descriptor on both the stub (client) and proxy (cluster) sides of Coherence*Extend-JMS.

On the proxy (cluster) side, where you need the Vehicles to be a Distributed cache (using the distributed cache-scheme), you would either not specify any command line override for this setting in the java command line, or specify distributed as follows:

java -Dcache-scheme=distributed -jar coherence.jar

On the stub (client) side, where you need the Vehicles to be a Local cache with a Coherence*Extend-JMS cache loader (using the configuration specified by the jms-local cache-scheme), you would specify the following command line override:

java -Dcache-scheme=local-jms -jar coherence.jar