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 com.tangosol.net.jms.AdapterFactory to instantiate the necessary implementations (stub and proxy) to support Coherence API calls over JMS.
The Coherence*Extend-JMS stub implements both the com.tangosol.net.NamedCache and com.tangosol.net.cache.CacheStore 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: [\d]+[[.][\d]+]?[MS|ms|S|s|M|m|H|h|D|d]? where the first non-digits (from left to right) indicate the unit of time duration:
If the value does not contain a unit, a unit of seconds is assumed.
|
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:
<cache-config>
<caching-scheme-mapping>
<cache-mapping>
<cache-name>Vehicles</cache-name>
<scheme-name system-property="cache-scheme">distributed</scheme-name>
</cache-mapping>
</caching-scheme-mapping>
<caching-schemes>
<local-scheme>
<scheme-name>jms-local</scheme-name>
<cachestore-scheme>
<jms-scheme>
<scheme-ref>jms-direct</scheme-ref>
</jms-scheme>
</cachestore-scheme>
</local-scheme>
<jms-scheme>
<scheme-name>jms-direct</scheme-name>
<queue-connection-factory-name>jms/coherence/ConnectionFactory</queue-connection-factory-name>
<topic-connection-factory-name>jms/coherence/ConnectionFactory</topic-connection-factory-name>
<queue-name>jms/coherence/Queue</queue-name>
<queue-name>jms/coherence/Topic</queue-name>
<request-timeout>10s</request-timeout>
</jms-scheme>
<distributed-scheme>
<scheme-name>distributed</scheme-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
</caching-schemes>
</cache-config>
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