jboss cluster 中java ee 核心服务，开发组建的集群化。
jboss cluster从2001年已经部署在jboss as 的all 配置中，用户只需要进行简单修改就能利用jboss cluster提供的强大功能。jboss cluster 是一组具有共同功能的节点的划分，一个节点可以是一台jboss as 机器，也可以使一台机器中多个 jboss as 实例（instance）中的一个，通过多个节点的架构，jboss cluster 就能实现容错恢复（fault tolerance ）和 负载均衡（load balancing 的目的，能容错恢复就能提高系统的可靠性，能负载均衡就能提高系统的性能。
jboss cluster 的特点：
1.集群中的节点通过底层软件jgroup的多播数据包能自动发现；
2.对jndi,ejb等容错回复和负载均衡。
3.对http session的复制等。
jboss cluser提供的ha-jndi 服务具有透明的容错回复，负载均衡，客户端自动发现，统一的jndi视图等，对于在同一as 中的客户端，只需在初始化initialContext时候，制定jnp.partitionname的值为你的分区名称；对于客户端在另一个jvm中 的客户端，则需要在初始化 initialContext时候，制定 prop.setProperty("java.naming.provider.url", "192.168.70.104:1099,192.168.45.146:1099");
在EJB3中需要使用注解类 org.jboss.ejb3.annotation.Clustered来设置负载均衡的策略和集群的分区参数， 默认的负载均衡策略为org.jboss.ha.framework.interfaces.RandomRobin，默认的分区为 DefaultPartition.
session bean:
org.jboss.ejb3.annotation.Clustered可以注解Stateless Bean 也可以直接Statefull bean ，只需要在bean 类前声明即可。如果是有状态的回话bean（statefull bean ）@Clustered注解即可.对于statefull有状态的session bean, 由于在调用函数间有状态，所以除了添加同样的@Clustered注解外，还有制定存储信息的状态cacheconfig注解。
entity bean:
在jboss cluster中，所有的节点里的entity bean 实例通过分布式缓存，复制来保持同步，通过持久化配置文件persistence.xml添加二级缓存来减少与数据库的往返，从而提供性能,同时给每一个entity bean 打上 org.hibernate.annotations.cache的注解。
JBOSS采用什么复制回话的状态呢？
答案是采用JBOSS Cache。JBOSS Cache 提供了分布式缓存和JBOSS Cluster的状态复制服务。一个JBOSS cluster 可以有多个JBOSS cache MBean（如众所周知TreeCache MBean）.
session bean:对于stateless 类型的session bean,只需要在该类制定
JBOSS采用什么复制回话的状态呢？
答案是采用JBOSS Cache。JBOSS Cache 提供了分布式缓存和JBOSS Cluster的状态复制服务。一个JBOSS cluster 可以有多个JBOSS cache MBean（如众所周知TreeCache MBean）.
相关的MBean服务的定义在jbossTBS-5.1.0.GA\server\all\deploy\cluster\jboss-cache-manager.sar\META-INF\jboss-cache-manager-jboss-beans.xml文件中。
内容如下：
<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="urn:jboss:bean-deployer:2.0">
<!-- Factory/registry for JBoss Cache and PojoCache instances used in the AS -->
<bean name="CacheManager" class="org.jboss.ha.cachemanager.CacheManager">
<annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss.cache:service=CacheManager", exposedInterface=org.jboss.ha.cachemanager.CacheManagerMBean.class, registerDirectly=true)</annotation>
<!-- This doesn't seem to work, so the service binds itself for now
<annotation>@org.jboss.aop.microcontainer.aspects.jndi.JndiBinding(name="java:CacheManager")</annotation>
-->
<property name="jndiName">java:CacheManager</property>
<property name="configurationRegistry"><inject bean="CacheConfigurationRegistry"/></property>
<property name="channelFactory"><inject bean="JChannelFactory"/></property>
<!-- Aliases for cache names. Allows caches to be shared across
services that may expect different cache config names. -->
<property name="configAliases">
<map keyClass="java.lang.String" valueClass="java.lang.String">
<!-- Use the HAPartition cache for ClusteredSSO caching -->
<entry>
<key>clustered-sso</key>
<value>ha-partition</value>
</entry>
<!-- Handle the legacy name for the EJB3 SFSB cache -->
<entry>
<key>jboss.cache:service=EJB3SFSBClusteredCache</key>
<value>sfsb-cache</value>
</entry>
<!-- Handle the legacy name for the EJB3 Entity cache -->
<entry>
<key>jboss.cache:service=EJB3EntityTreeCache</key>
<value>mvcc-shared</value>
</entry>
</map>
</property>
<!-- Start these caches as part of the start of this CacheManager
<property name="eagerStartCaches">
<set>
<value>ha-partition</value>
</set>
</property>
-->
</bean>
<!--
| Registry of named JBoss Cache configurations. Users of the CacheManager
| request a cache with a particular configuration by providing the name
| of one of these configurations.
-->
<bean name="CacheConfigurationRegistry" class="org.jboss.ha.cachemanager.DependencyInjectedConfigurationRegistry">
<!-- If users wish to add configs using a more familiar JBC config format
they can add them to a cache-configs.xml file specified by this property.
However, use of the microcontainer format used below is recommended.
<property name="configResource">META-INF/jboss-cache-configs.xml</property>
-->
<!-- The configurations. A Map<String name, Configuration config> -->
<property name="newConfigurations">
<map keyClass="java.lang.String" valueClass="org.jboss.cache.config.Configuration">
<!-- The standard configurations follow. You can add your own and/or edit these. -->
<!-- Standard cache used for web sessions -->
<entry><key>standard-session-cache</key>
<value>
<bean name="StandardSessionCacheConfig" class="org.jboss.cache.config.Configuration">
<!-- Provides batching functionality for caches that don't want to interact with regular JTA Transactions -->
<property name="transactionManagerLookupClass">org.jboss.cache.transaction.BatchModeTransactionManagerLookup</property>
<!-- Name of cluster. Needs to be the same for all members -->
<property name="clusterName">${jboss.partition.name:DefaultPartition}-SessionCache</property>
<!-- Use a UDP (multicast) based stack. Need JGroups flow control (FC)
because we are using asynchronous replication. -->
<property name="multiplexerStack">${jboss.default.jgroups.stack:udp}</property>
<property name="fetchInMemoryState">true</property>
<property name="nodeLockingScheme">PESSIMISTIC</property>
<property name="isolationLevel">REPEATABLE_READ</property>
<property name="useLockStriping">false</property>
<property name="cacheMode">REPL_ASYNC</property>
<!-- Number of milliseconds to wait until all responses for a
synchronous call have been received. Make this longer
than lockAcquisitionTimeout.-->
<property name="syncReplTimeout">17500</property>
<!-- Max number of milliseconds to wait for a lock acquisition -->
<property name="lockAcquisitionTimeout">15000</property>
<!-- The max amount of time (in milliseconds) we wait until the
state (ie. the contents of the cache) are retrieved from
existing members at startup. -->
<property name="stateRetrievalTimeout">60000</property>
<!-- Not needed for a web session cache that doesn't use FIELD -->
<property name="useRegionBasedMarshalling">false</property>
<!-- Must match the value of "useRegionBasedMarshalling" -->
<property name="inactiveOnStartup">false</property>
<!-- Disable asynchronous RPC marshalling/sending -->
<property name="serializationExecutorPoolSize">0</property>
<!-- We have no asynchronous notification listeners -->
<property name="listenerAsyncPoolSize">0</property>
<property name="exposeManagementStatistics">true</property>
<property name="buddyReplicationConfig">
<bean class="org.jboss.cache.config.BuddyReplicationConfig">
<!-- Just set to true to turn on buddy replication -->
<property name="enabled">false</property>
<!-- A way to specify a preferred replication group. We try
and pick a buddy who shares the same pool name (falling
back to other buddies if not available). -->
<property name="buddyPoolName">default</property>
<property name="buddyCommunicationTimeout">17500</property>
<!-- Do not change these -->
<property name="autoDataGravitation">false</property>
<property name="dataGravitationRemoveOnFind">true</property>
<property name="dataGravitationSearchBackupTrees">true</property>
<property name="buddyLocatorConfig">
<bean class="org.jboss.cache.buddyreplication.NextMemberBuddyLocatorConfig">
<!-- The number of backup copies we maintain -->
<property name="numBuddies">1</property>
<!-- Means that each node will *try* to select a buddy on
a different physical host. If not able to do so
though, it will fall back to colocated nodes. -->
<property name="ignoreColocatedBuddies">true</property>
</bean>
</property>
</bean>
</property>
<property name="cacheLoaderConfig">
<bean class="org.jboss.cache.config.CacheLoaderConfig">
<!-- Do not change these -->
<property name="passivation">true</property>
<property name="shared">false</property>
<property name="individualCacheLoaderConfigs">
<list>
<bean class="org.jboss.cache.loader.FileCacheLoaderConfig">
<!-- Where passivated sessions are stored -->
<property name="location">${jboss.server.data.dir}${/}session</property>
<!-- Do not change these -->
<property name="async">false</property>
<property name="fetchPersistentState">true</property>
<property name="purgeOnStartup">true</property>
<property name="ignoreModifications">false</property>
<property name="checkCharacterPortability">false</property>
</bean>
</list>
</property>
</bean>
</property>
</bean>
</value>
</entry>
<!-- Appropriate for web sessions with FIELD granularity -->
<entry><key>field-granularity-session-cache</key>
<value>
<bean name="FieldSessionCacheConfig" class="org.jboss.cache.config.Configuration">
<!-- Provides batching functionality for caches that don't want to interact with regular JTA Transactions -->
<property name="transactionManagerLookupClass">org.jboss.cache.transaction.BatchModeTransactionManagerLookup</property>
<!-- Name of cluster. Needs to be the same for all members -->
<property name="clusterName">${jboss.partition.name:DefaultPartition}-FieldSessionCache</property>
<!-- Use a UDP (multicast) based stack. Need JGroups flow control (FC)
because we are using asynchronous replication. -->
<property name="multiplexerStack">${jboss.default.jgroups.stack:udp}</property>
<property name="fetchInMemoryState">true</property>
<property name="nodeLockingScheme">PESSIMISTIC</property>
<property name="isolationLevel">REPEATABLE_READ</property>
<property name="useLockStriping">false</property>
<property name="cacheMode">REPL_ASYNC</property>
<property name="syncReplTimeout">17500</property>
<property name="lockAcquisitionTimeout">15000</property>
<property name="stateRetrievalTimeout">60000</property>
<!-- Field granularity requires region-based marshalling -->
<property name="useRegionBasedMarshalling">true</property>
<!-- Must match the value of "useRegionBasedMarshalling" -->
<property name="inactiveOnStartup">true</property>
<!-- Disable asynchronous RPC marshalling/sending -->
<property name="serializationExecutorPoolSize">0</property>
<!-- We have no asynchronous notification listeners -->
<property name="listenerAsyncPoolSize">0</property>
<property name="exposeManagementStatistics">true</property>
<property name="buddyReplicationConfig">
<bean class="org.jboss.cache.config.BuddyReplicationConfig">
<!-- Just set to true to turn on buddy replication -->
<property name="enabled">false</property>
<!-- A way to specify a preferred replication group. We try
and pick a buddy who shares the same pool name (falling
back to other buddies if not available). -->
<property name="buddyPoolName">default</property>
<property name="buddyCommunicationTimeout">17500</property>
<!-- Do not change these -->
<property name="autoDataGravitation">false</property>
<property name="dataGravitationRemoveOnFind">true</property>
<property name="dataGravitationSearchBackupTrees">true</property>
<property name="buddyLocatorConfig">
<bean class="org.jboss.cache.buddyreplication.NextMemberBuddyLocatorConfig">
<!-- The number of backup nodes we maintain -->
<property name="numBuddies">1</property>
<!-- Means that each node will *try* to select a buddy on
a different physical host. If not able to do so
though, it will fall back to colocated nodes. -->
<property name="ignoreColocatedBuddies">true</property>
</bean>
</property>
</bean>
</property>
<property name="cacheLoaderConfig">
<bean class="org.jboss.cache.config.CacheLoaderConfig">
<!-- Do not change these -->
<property name="passivation">true</property>
<property name="shared">false</property>
<property name="individualCacheLoaderConfigs">
<list>
<bean class="org.jboss.cache.loader.FileCacheLoaderConfig">
<!-- Where passivated sessions are stored -->
<property name="location">${jboss.server.data.dir}${/}field-session</property>
<!-- Do not change these -->
<property name="async">false</property>
<property name="fetchPersistentState">true</property>
<property name="purgeOnStartup">true</property>
<property name="ignoreModifications">false</property>
<property name="checkCharacterPortability">false</property>
</bean>
</list>
</property>
</bean>
</property>
</bean>
</value>
</entry>
<!-- Standard cache used for EJB3 SFSB caching -->
<entry><key>sfsb-cache</key>
<value>
<bean name="StandardSFSBCacheConfig" class="org.jboss.cache.config.Configuration">
<!-- No transaction manager lookup -->
<!-- Name of cluster. Needs to be the same for all members -->
<property name="clusterName">${jboss.partition.name:DefaultPartition}-SFSBCache</property>
<!-- Use a UDP (multicast) based stack. Need JGroups flow control (FC)
because we are using asynchronous replication. -->
<property name="multiplexerStack">${jboss.default.jgroups.stack:udp}</property>
<property name="fetchInMemoryState">true</property>
<property name="nodeLockingScheme">PESSIMISTIC</property>
<property name="isolationLevel">REPEATABLE_READ</property>
<property name="useLockStriping">false</property>
<property name="cacheMode">REPL_ASYNC</property>
<!-- Number of milliseconds to wait until all responses for a
synchronous call have been received. Make this longer
than lockAcquisitionTimeout.-->
<property name="syncReplTimeout">17500</property>
<!-- Max number of milliseconds to wait for a lock acquisition -->
<property name="lockAcquisitionTimeout">15000</property>
<!-- The max amount of time (in milliseconds) we wait until the
state (ie. the contents of the cache) are retrieved from
existing members at startup. -->
<property name="stateRetrievalTimeout">60000</property>
<!--
SFSBs use region-based marshalling to provide for partial state
transfer during deployment/undeployment.
-->
<property name="useRegionBasedMarshalling">false</property>
<!-- Must match the value of "useRegionBasedMarshalling" -->
<property name="inactiveOnStartup">false</property>
<!-- Disable asynchronous RPC marshalling/sending -->
<property name="serializationExecutorPoolSize">0</property>
<!-- We have no asynchronous notification listeners -->
<property name="listenerAsyncPoolSize">0</property>
<property name="exposeManagementStatistics">true</property>
<property name="buddyReplicationConfig">
<bean class="org.jboss.cache.config.BuddyReplicationConfig">
<!-- Just set to true to turn on buddy replication -->
<property name="enabled">false</property>
<!-- A way to specify a preferred replication group. We try
and pick a buddy who shares the same pool name (falling
back to other buddies if not available). -->
<property name="buddyPoolName">default</property>
<property name="buddyCommunicationTimeout">17500</property>
<!-- Do not change these -->
<property name="autoDataGravitation">false</property>
<property name="dataGravitationRemoveOnFind">true</property>
<property name="dataGravitationSearchBackupTrees">true</property>
<property name="buddyLocatorConfig">
<bean class="org.jboss.cache.buddyreplication.NextMemberBuddyLocatorConfig">
<!-- The number of backup nodes we maintain -->
<property name="numBuddies">1</property>
<!-- Means that each node will *try* to select a buddy on
a different physical host. If not able to do so
though, it will fall back to colocated nodes. -->
<property name="ignoreColocatedBuddies">true</property>
</bean>
</property>
</bean>
</property>
<property name="cacheLoaderConfig">
<bean class="org.jboss.cache.config.CacheLoaderConfig">
<!-- Do not change these -->
<property name="passivation">true</property>
<property name="shared">false</property>
<property name="individualCacheLoaderConfigs">
<list>
<bean class="org.jboss.cache.loader.FileCacheLoaderConfig">
<!-- Where passivated sessions are stored -->
<property name="location">${jboss.server.data.dir}${/}sfsb</property>
<!-- Do not change these -->
<property name="async">false</property>
<property name="fetchPersistentState">true</property>
<property name="purgeOnStartup">true</property>
<property name="ignoreModifications">false</property>
<property name="checkCharacterPortability">false</property>
</bean>
</list>
</property>
</bean>
</property>
<!-- EJBs use JBoss Cache eviction -->
<property name="evictionConfig">
<bean class="org.jboss.cache.config.EvictionConfig">
<property name="wakeupInterval">5000</property>
<!-- Overall default -->
<property name="defaultEvictionRegionConfig">
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.NullEvictionAlgorithmConfig"/>
</property>
</bean>
</property>
<!-- EJB3 integration code will programatically create
other regions as beans are deployed -->
</bean>
</property>
</bean>
</value>
</entry>
<!--
Appropriate for the HAPartition-based services, e.g. DistributedState,
HA-JNDI. Also valid for use by the JBossWeb ClusteredSingleSignOn valve.
-->
<entry><key>ha-partition</key>
<value>
<bean name="HAPartitionCache" class="org.jboss.cache.config.Configuration">
<!-- Provides batching functionality for caches that don't want to interact with regular JTA Transactions -->
<property name="transactionManagerLookupClass">org.jboss.cache.transaction.BatchModeTransactionManagerLookup</property>
<property name="clusterName">${jboss.partition.name:DefaultPartition}-HAPartitionCache</property>
<property name="multiplexerStack">${jboss.default.jgroups.stack:udp}</property>
<property name="fetchInMemoryState">true</property>
<property name="nodeLockingScheme">PESSIMISTIC</property>
<property name="isolationLevel">REPEATABLE_READ</property>
<property name="useLockStriping">false</property>
<property name="cacheModeString">REPL_SYNC</property>
<property name="syncReplTimeout">17500</property>
<property name="lockAcquisitionTimeout">15000</property>
<property name="stateRetrievalTimeout">60000</property>
<property name="useRegionBasedMarshalling">false</property>
<property name="inactiveOnStartup">false</property>
<!-- Disable asynchronous RPC marshalling/sending -->
<property name="serializationExecutorPoolSize">0</property>
<!-- We have no asynchronous notification listeners -->
<property name="listenerAsyncPoolSize">0</property>
<property name="exposeManagementStatistics">true</property>
</bean>
</value>
</entry>
<!--
Following are JBoss Cache configurations suitable for different
Hibernate 2nd Level Cache uses (e.g. entities vs. queries).
In all cases, TransactionManager configuration not required.
Hibernate will plug in its own transaction manager integration.
-->
<!-- A config appropriate for entity/collection caching that uses MVCC locking -->
<entry><key>mvcc-entity</key>
<value>
<bean name="MVCCEntityCache" class="org.jboss.cache.config.Configuration">
<!-- Node locking scheme -->
<property name="nodeLockingScheme">MVCC</property>
<!-- READ_COMMITTED is as strong as necessary for most
2nd Level Cache use cases. -->
<property name="isolationLevel">READ_COMMITTED</property>
<property name="useLockStriping">false</property>
<!-- Mode of communication with peer caches.
INVALIDATION_SYNC is highly recommended as the mode for use
with entity and collection caches. -->
<property name="cacheMode">INVALIDATION_SYNC</property>
<!-- Name of cluster. Needs to be the same for all members -->
<property name="clusterName">${jboss.partition.name:DefaultPartition}-mvcc-entity</property>
<!-- Use a UDP (multicast) based stack. A udp-sync stack might be
slightly better (no JGroups FC) but we stick with udp to
help ensure this cache and others like timestamps-cache
that require FC can use the same underlying JGroups resources. -->
<property name="multiplexerStack">${jboss.default.jgroups.stack:udp}</property>
<!-- Whether or not to fetch state on joining a cluster. -->
<property name="fetchInMemoryState">false</property>
<!-- The max amount of time (in milliseconds) we wait until the
state (ie. the contents of the cache) are retrieved from
existing members at startup. Ignored if FetchInMemoryState=false. -->
<property name="stateRetrievalTimeout">60000</property>
<!-- Number of milliseconds to wait until all responses for a
synchronous call have been received. -->
<property name="syncReplTimeout">17500</property>
<!-- Max number of milliseconds to wait for a lock acquisition -->
<property name="lockAcquisitionTimeout">15000</property>
<!-- Hibernate 2LC can replicate custom types, so we use marshalling -->
<property name="useRegionBasedMarshalling">true</property>
<!-- Must match the value of "useRegionBasedMarshalling" -->
<property name="inactiveOnStartup">true</property>
<!-- Disable asynchronous RPC marshalling/sending -->
<property name="serializationExecutorPoolSize">0</property>
<!-- We have no asynchronous notification listeners -->
<property name="listenerAsyncPoolSize">0</property>
<property name="evictionConfig">
<bean class="org.jboss.cache.config.EvictionConfig">
<property name="wakeupInterval">5000</property>
<!-- Overall default -->
<property name="defaultEvictionRegionConfig">
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.LRUAlgorithmConfig">
<!-- Evict LRU node once we have more than this number of nodes -->
<property name="maxNodes">10000</property>
<!-- And, evict any node that hasn't been accessed in this many seconds -->
<property name="timeToLiveSeconds">1000</property>
<!-- Don't evict a node that's been accessed within this many seconds.
Set this to a value greater than your max expected transaction length. -->
<property name="minTimeToLiveSeconds">120</property>
</bean>
</property>
</bean>
</property>
<property name="evictionRegionConfigs">
<list>
<!-- Don't ever evict modification timestamps -->
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/TS</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.NullEvictionAlgorithmConfig"/>
</property>
</bean>
</list>
</property>
</bean>
</property>
</bean>
</value>
</entry>
<!-- A config appropriate for entity/collection caching that uses optimistic locking. -->
<entry><key>optimistic-entity</key>
<value>
<bean name="OptimisticEntityCache" class="org.jboss.cache.config.Configuration">
<!-- Node locking scheme -->
<property name="nodeLockingScheme">OPTIMISTIC</property>
<!-- Mode of communication with peer caches.
INVALIDATION_SYNC is highly recommended as the mode for use
with entity and collection caches. -->
<property name="cacheMode">INVALIDATION_SYNC</property>
<property name="useLockStriping">false</property>
<!-- Name of cluster. Needs to be the same for all members -->
<property name="clusterName">${jboss.partition.name:DefaultPartition}-opt-entity</property>
<!-- Use a UDP (multicast) based stack. A udp-sync stack might be
slightly better (no JGroups FC) but we stick with udp to
help ensure this cache and others like timestamps-cache
that require FC can use the same underlying JGroups resources. -->
<property name="multiplexerStack">${jboss.default.jgroups.stack:udp}</property>
<!-- Whether or not to fetch state on joining a cluster. -->
<property name="fetchInMemoryState">false</property>
<!-- The max amount of time (in milliseconds) we wait until the
state (ie. the contents of the cache) are retrieved from
existing members at startup. Ignored if FetchInMemoryState=false. -->
<property name="stateRetrievalTimeout">60000</property>
<!-- Number of milliseconds to wait until all responses for a
synchronous call have been received. -->
<property name="syncReplTimeout">17500</property>
<!-- Max number of milliseconds to wait for a lock acquisition -->
<property name="lockAcquisitionTimeout">15000</property>
<!-- Hibernate 2LC can replicate custom types, so we use marshalling -->
<property name="useRegionBasedMarshalling">true</property>
<!-- Must match the value of "useRegionBasedMarshalling" -->
<property name="inactiveOnStartup">true</property>
<!-- Disable asynchronous RPC marshalling/sending -->
<property name="serializationExecutorPoolSize">0</property>
<!-- We have no asynchronous notification listeners -->
<property name="listenerAsyncPoolSize">0</property>
<property name="evictionConfig">
<bean class="org.jboss.cache.config.EvictionConfig">
<property name="wakeupInterval">5000</property>
<!-- Overall default -->
<property name="defaultEvictionRegionConfig">
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.LRUAlgorithmConfig">
<!-- Evict LRU node once we have more than this number of nodes -->
<property name="maxNodes">10000</property>
<!-- And, evict any node that hasn't been accessed in this many seconds -->
<property name="timeToLiveSeconds">1000</property>
<!-- Don't evict a node that's been accessed within this many seconds.
Set this to a value greater than your max expected transaction length. -->
<property name="minTimeToLiveSeconds">120</property>
</bean>
</property>
</bean>
</property>
<property name="evictionRegionConfigs">
<list>
<!-- Don't ever evict modification timestamps -->
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/TS</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.NullEvictionAlgorithmConfig"/>
</property>
</bean>
</list>
</property>
</bean>
</property>
</bean>
</value>
</entry>
<!-- A config appropriate for entity/collection caching that uses pessimistic locking -->
<entry><key>pessimistic-entity</key>
<value>
<bean name="PessimisticEntityCache" class="org.jboss.cache.config.Configuration">
<!-- Node locking scheme -->
<property name="nodeLockingScheme">PESSIMISTIC</property>
<!-- READ_COMMITTED is as strong as necessary for most
2nd Level Cache use cases. -->
<property name="isolationLevel">READ_COMMITTED</property>
<property name="useLockStriping">false</property>
<!-- Mode of communication with peer caches.
INVALIDATION_SYNC is highly recommended as the mode for use
with entity and collection caches. -->
<property name="cacheMode">INVALIDATION_SYNC</property>
<!-- Name of cluster. Needs to be the same for all members -->
<property name="clusterName">${jboss.partition.name:DefaultPartition}-pess-entity</property>
<!-- Use a UDP (multicast) based stack. A udp-sync stack might be
slightly better (no JGroups FC) but we stick with udp to
help ensure this cache and others like timestamps-cache
that require FC can use the same underlying JGroups resources. -->
<property name="multiplexerStack">${jboss.default.jgroups.stack:udp}</property>
<!-- Whether or not to fetch state on joining a cluster. -->
<property name="fetchInMemoryState">false</property>
<!-- The max amount of time (in milliseconds) we wait until the
state (ie. the contents of the cache) are retrieved from
existing members at startup. Ignored if FetchInMemoryState=false. -->
<property name="stateRetrievalTimeout">60000</property>
<!-- Number of milliseconds to wait until all responses for a
synchronous call have been received. -->
<property name="syncReplTimeout">17500</property>
<!-- Max number of milliseconds to wait for a lock acquisition -->
<property name="lockAcquisitionTimeout">15000</property>
<!-- Hibernate 2LC can replicate custom types, so we use marshalling -->
<property name="useRegionBasedMarshalling">true</property>
<!-- Must match the value of "useRegionBasedMarshalling" -->
<property name="inactiveOnStartup">true</property>
<!-- Disable asynchronous RPC marshalling/sending -->
<property name="serializationExecutorPoolSize">0</property>
<!-- We have no asynchronous notification listeners -->
<property name="listenerAsyncPoolSize">0</property>
<property name="evictionConfig">
<bean class="org.jboss.cache.config.EvictionConfig">
<property name="wakeupInterval">5000</property>
<!-- Overall default -->
<property name="defaultEvictionRegionConfig">
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.LRUAlgorithmConfig">
<!-- Evict LRU node once we have more than this number of nodes -->
<property name="maxNodes">10000</property>
<!-- And, evict any node that hasn't been accessed in this many seconds -->
<property name="timeToLiveSeconds">1000</property>
<!-- Don't evict a node that's been accessed within this many seconds.
Set this to a value greater than your max expected transaction length. -->
<property name="minTimeToLiveSeconds">120</property>
</bean>
</property>
</bean>
</property>
<property name="evictionRegionConfigs">
<list>
<!-- Don't ever evict modification timestamps -->
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/TS</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.NullEvictionAlgorithmConfig"/>
</property>
</bean>
</list>
</property>
</bean>
</property>
</bean>
</value>
</entry>
<!-- Same as "mvcc-entity" but here we use REPEATABLE_READ
instead of READ_COMMITTED. REPEATABLE_READ is only useful if the
application evicts/clears entities from the Hibernate Session and
then expects to repeatably re-read them in the same transaction.
Otherwise, the Session's internal cache provides a repeatable-read
semantic. Before choosing this config, carefully read the docs
and make sure you really need REPEATABLE_READ. -->
<entry><key>mvcc-entity-repeatable</key>
<value>
<bean name="MVCCEntityRepeatableCache" class="org.jboss.cache.config.Configuration">
<!-- Node locking scheme -->
<property name="nodeLockingScheme">MVCC</property>
<!-- Here we use REPEATABLE_READ. -->
<property name="isolationLevel">READ_COMMITTED</property>
<property name="useLockStriping">false</property>
<!-- Mode of communication with peer caches.
INVALIDATION_SYNC is highly recommended as the mode for use
with entity and collection caches. -->
<property name="cacheMode">INVALIDATION_SYNC</property>
<!-- Name of cluster. Needs to be the same for all members -->
<property name="clusterName">${jboss.partition.name:DefaultPartition}-mvcc-entity-rr</property>
<!-- Use a UDP (multicast) based stack. A udp-sync stack might be
slightly better (no JGroups FC) but we stick with udp to
help ensure this cache and others like timestamps-cache
that require FC can use the same underlying JGroups resources. -->
<property name="multiplexerStack">${jboss.default.jgroups.stack:udp}</property>
<!-- Whether or not to fetch state on joining a cluster. -->
<property name="fetchInMemoryState">false</property>
<!-- The max amount of time (in milliseconds) we wait until the
state (ie. the contents of the cache) are retrieved from
existing members at startup. Ignored if FetchInMemoryState=false. -->
<property name="stateRetrievalTimeout">60000</property>
<!-- Number of milliseconds to wait until all responses for a
synchronous call have been received. -->
<property name="syncReplTimeout">17500</property>
<!-- Max number of milliseconds to wait for a lock acquisition -->
<property name="lockAcquisitionTimeout">15000</property>
<!-- Hibernate 2LC can replicate custom types, so we use marshalling -->
<property name="useRegionBasedMarshalling">true</property>
<!-- Must match the value of "useRegionBasedMarshalling" -->
<property name="inactiveOnStartup">true</property>
<!-- Disable asynchronous RPC marshalling/sending -->
<property name="serializationExecutorPoolSize">0</property>
<!-- We have no asynchronous notification listeners -->
<property name="listenerAsyncPoolSize">0</property>
<property name="evictionConfig">
<bean class="org.jboss.cache.config.EvictionConfig">
<property name="wakeupInterval">5000</property>
<!-- Overall default -->
<property name="defaultEvictionRegionConfig">
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.LRUAlgorithmConfig">
<!-- Evict LRU node once we have more than this number of nodes -->
<property name="maxNodes">10000</property>
<!-- And, evict any node that hasn't been accessed in this many seconds -->
<property name="timeToLiveSeconds">1000</property>
<!-- Don't evict a node that's been accessed within this many seconds.
Set this to a value greater than your max expected transaction length. -->
<property name="minTimeToLiveSeconds">120</property>
</bean>
</property>
</bean>
</property>
<property name="evictionRegionConfigs">
<list>
<!-- Don't ever evict modification timestamps -->
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/TS</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.NullEvictionAlgorithmConfig"/>
</property>
</bean>
</list>
</property>
</bean>
</property>
</bean>
</value>
</entry>
<!-- Same as "pessimistic-entity" but here we use REPEATABLE_READ
instead of READ_COMMITTED. REPEATABLE_READ is only useful if the
application evicts/clears entities from the Hibernate Session and
then expects to repeatably re-read them in the same transaction.
Otherwise, the Session's internal cache provides a repeatable-read
semantic. Before choosing this config, carefully read the docs
and make sure you really need REPEATABLE_READ.
-->
<entry><key>pessimistic-entity-repeatable</key>
<value>
<bean name="PessimisticEntityRepeatableCache" class="org.jboss.cache.config.Configuration">
<!-- Node locking scheme -->
<property name="nodeLockingScheme">PESSIMISTIC</property>
<property name="isolationLevel">REPEATABLE_READ</property>
<property name="useLockStriping">false</property>
<!-- Mode of communication with peer caches.
INVALIDATION_SYNC is highly recommended as the mode for use
with entity and collection caches. -->
<property name="cacheMode">INVALIDATION_SYNC</property>
<!-- Name of cluster. Needs to be the same for all members -->
<property name="clusterName">${jboss.partition.name:DefaultPartition}-pess-entity-rr</property>
<!-- Use a UDP (multicast) based stack. A udp-sync stack might be
slightly better (no JGroups FC) but we stick with udp to
help ensure this cache and others like timestamps-cache
that require FC can use the same underlying JGroups resources. -->
<property name="multiplexerStack">${jboss.default.jgroups.stack:udp}</property>
<!-- Whether or not to fetch state on joining a cluster. -->
<property name="fetchInMemoryState">false</property>
<!-- The max amount of time (in milliseconds) we wait until the
state (ie. the contents of the cache) are retrieved from
existing members at startup. Ignored if FetchInMemoryState=false. -->
<property name="stateRetrievalTimeout">60000</property>
<!-- Number of milliseconds to wait until all responses for a
synchronous call have been received. -->
<property name="syncReplTimeout">17500</property>
<!-- Max number of milliseconds to wait for a lock acquisition -->
<property name="lockAcquisitionTimeout">15000</property>
<!-- Hibernate 2LC can replicate custom types, so we use marshalling -->
<property name="useRegionBasedMarshalling">true</property>
<!-- Must match the value of "useRegionBasedMarshalling" -->
<property name="inactiveOnStartup">true</property>
<!-- Disable asynchronous RPC marshalling/sending -->
<property name="serializationExecutorPoolSize">0</property>
<!-- We have no asynchronous notification listeners -->
<property name="listenerAsyncPoolSize">0</property>
<property name="evictionConfig">
<bean class="org.jboss.cache.config.EvictionConfig">
<property name="wakeupInterval">5000</property>
<!-- Overall default -->
<property name="defaultEvictionRegionConfig">
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.LRUAlgorithmConfig">
<!-- Evict LRU node once we have more than this number of nodes -->
<property name="maxNodes">10000</property>
<!-- And, evict any node that hasn't been accessed in this many seconds -->
<property name="timeToLiveSeconds">1000</property>
<!-- Don't evict a node that's been accessed within this many seconds.
Set this to a value greater than your max expected transaction length. -->
<property name="minTimeToLiveSeconds">120</property>
</bean>
</property>
</bean>
</property>
<property name="evictionRegionConfigs">
<list>
<!-- Don't ever evict modification timestamps -->
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/TS</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.NullEvictionAlgorithmConfig"/>
</property>
</bean>
</list>
</property>
</bean>
</property>
</bean>
</value>
</entry>
<!-- A config appropriate for query caching. Does not replicate
queries. DO NOT STORE TIMESTAMPS IN THIS CACHE. -->
<entry><key>local-query</key>
<value>
<bean name="LocalQueryCache" class="org.jboss.cache.config.Configuration">
<!-- Node locking scheme -->
<property name="nodeLockingScheme">OPTIMISTIC</property>
<property name="useLockStriping">false</property>
<!-- LOCAL means don't communicate with other caches. -->
<property name="cacheMode">LOCAL</property>
<!-- Max number of milliseconds to wait for a lock acquisition -->
<property name="lockAcquisitionTimeout">15000</property>
<!-- We have no asynchronous notification listeners -->
<property name="listenerAsyncPoolSize">0</property>
<property name="evictionConfig">
<bean class="org.jboss.cache.config.EvictionConfig">
<property name="wakeupInterval">5000</property>
<!-- Overall default -->
<property name="defaultEvictionRegionConfig">
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.LRUAlgorithmConfig">
<!-- Evict LRU node once we have more than this number of nodes -->
<property name="maxNodes">10000</property>
<!-- And, evict any node that hasn't been accessed in this many seconds -->
<property name="timeToLiveSeconds">1000</property>
<!-- Don't evict a node that's been accessed within this many seconds.
Set this to a value greater than your max expected transaction length. -->
<property name="minTimeToLiveSeconds">120</property>
</bean>
</property>
</bean>
</property>
<property name="evictionRegionConfigs">
<list>
<!-- Don't ever evict modification timestamps -->
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/TS</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.NullEvictionAlgorithmConfig"/>
</property>
</bean>
</list>
</property>
</bean>
</property>
</bean>
</value>
</entry>
<!-- A query cache that replicates querie results. Replication is asynchronous.
DO NOT STORE TIMESTAMPS IN THIS CACHE as no initial state transfer
is performed. -->
<entry><key>replicated-query</key>
<value>
<bean name="ReplicatedQueryCache" class="org.jboss.cache.config.Configuration">
<!-- Node locking scheme -->
<property name="nodeLockingScheme">OPTIMISTIC</property>
<property name="useLockStriping">false</property>
<!-- Mode of communication with peer caches.
REPL_ASYNC means replicate but sender does not block waiting for
peers to acknowledge applying the change. Valid for queries as
the timestamp cache mechanism will allow Hibernate to discard
out-of-date queries. -->
<property name="cacheMode">REPL_ASYNC</property>
<!-- Name of cluster. Needs to be the same for all members -->
<property name="clusterName">${jboss.partition.name:DefaultPartition}-query</property>
<!-- Use a UDP (multicast) based stack. Need JGroups flow control (FC)
because timestamp communication will not require a synchronous response. -->
<property name="multiplexerStack">${jboss.default.jgroups.stack:udp}</property>
<!-- Whether or not to fetch state on joining a cluster. -->
<property name="fetchInMemoryState">false</property>
<!-- The max amount of time (in milliseconds) we wait until the
state (ie. the contents of the cache) are retrieved from
existing members at startup. Ignored if FetchInMemoryState=false. -->
<property name="stateRetrievalTimeout">60000</property>
<!-- Number of milliseconds to wait until all responses for a
synchronous call have been received. -->
<property name="syncReplTimeout">17500</property>
<!-- Max number of milliseconds to wait for a lock acquisition -->
<property name="lockAcquisitionTimeout">15000</property>
<!-- Hibernate 2LC can replicate custom types, so we use marshalling -->
<property name="useRegionBasedMarshalling">true</property>
<!-- Must match the value of "useRegionBasedMarshalling" -->
<property name="inactiveOnStartup">true</property>
<!-- Disable asynchronous RPC marshalling/sending -->
<property name="serializationExecutorPoolSize">0</property>
<!-- We have no asynchronous notification listeners -->
<property name="listenerAsyncPoolSize">0</property>
<property name="evictionConfig">
<bean class="org.jboss.cache.config.EvictionConfig">
<property name="wakeupInterval">5000</property>
<!-- Overall default -->
<property name="defaultEvictionRegionConfig">
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.LRUAlgorithmConfig">
<!-- Evict LRU node once we have more than this number of nodes -->
<property name="maxNodes">10000</property>
<!-- And, evict any node that hasn't been accessed in this many seconds -->
<property name="timeToLiveSeconds">1000</property>
<!-- Don't evict a node that's been accessed within this many seconds.
Set this to a value greater than your max expected transaction length. -->
<property name="minTimeToLiveSeconds">120</property>
</bean>
</property>
</bean>
</property>
<property name="evictionRegionConfigs">
<list>
<!-- Don't ever evict modification timestamps -->
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/TS</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.NullEvictionAlgorithmConfig"/>
</property>
</bean>
</list>
</property>
</bean>
</property>
</bean>
</value>
</entry>
<!-- Optimized for timestamp caching. A clustered timestamp cache
is required if query caching is used, even if the query cache
itself is configured with CacheMode=LOCAL.
-->
<entry><key>timestamps-cache</key>
<value>
<bean name="TimestampsCache" class="org.jboss.cache.config.Configuration">
<!-- Node locking scheme -->
<property name="nodeLockingScheme">MVCC</property>
<!-- READ_COMMITTED is as strong as necessary -->
<property name="isolationLevel">READ_COMMITTED</property>
<property name="useLockStriping">false</property>
<!-- Cannot be INVALIDATION. ASYNC for improved performance. -->
<property name="cacheMode">REPL_ASYNC</property>
<!-- Name of cluster. Needs to be the same for all members -->
<property name="clusterName">${jboss.partition.name:DefaultPartition}-timestamps</property>
<!-- Use a UDP (multicast) based stack. Need JGroups flow control (FC)
because timestamp communication will not require a synchronous response. -->
<property name="multiplexerStack">${jboss.default.jgroups.stack:udp}</property>
<!-- Used for timestamps, so must fetch state. -->
<property name="fetchInMemoryState">true</property>
<!-- The max amount of time (in milliseconds) we wait until the
state (ie. the contents of the cache) are retrieved from
existing members at startup. Ignored if FetchInMemoryState=false. -->
<property name="stateRetrievalTimeout">60000</property>
<!-- Number of milliseconds to wait until all responses for a
synchronous call have been received. -->
<property name="syncReplTimeout">17500</property>
<!-- Max number of milliseconds to wait for a lock acquisition -->
<property name="lockAcquisitionTimeout">15000</property>
<!-- Hibernate 2LC can replicate custom types, so we use marshalling -->
<property name="useRegionBasedMarshalling">true</property>
<!-- Must match the value of "useRegionBasedMarshalling" -->
<property name="inactiveOnStartup">true</property>
<!-- Disable asynchronous RPC marshalling/sending -->
<property name="serializationExecutorPoolSize">0</property>
<!-- We have no asynchronous notification listeners -->
<property name="listenerAsyncPoolSize">0</property>
<!-- We should never evict timestamps, so eviction is disabled -->
</bean>
</value>
</entry>
<!-- A config appropriate for a cache that's shared for
entity, collection, query and timestamp caching. Not an advised
configuration, since it requires cache mode REPL_SYNC, which is the
least efficient mode. Also requires a full state transfer at startup,
which can be expensive. Uses mvcc locking. -->
<entry><key>mvcc-shared</key>
<value>
<bean name="MVCCSharedCache" class="org.jboss.cache.config.Configuration">
<!-- Node locking scheme -->
<property name="nodeLockingScheme">MVCC</property>
<!-- READ_COMMITTED is as strong as necessary for most
2nd Level Cache use cases. -->
<property name="isolationLevel">READ_COMMITTED</property>
<property name="useLockStriping">false</property>
<!-- Must use REPL since used for timestamp caching.
Must use SYNC to maintain cache coherency for entities. -->
<property name="cacheMode">REPL_SYNC</property>
<!-- Name of cluster. Needs to be the same for all members -->
<property name="clusterName">${jboss.partition.name:DefaultPartition}-mvcc-shared</property>
<!-- Use a UDP (multicast) based stack. Need JGroups flow control (FC)
because timestamp communication will not require a synchronous response. -->
<property name="multiplexerStack">${jboss.default.jgroups.stack:udp}</property>
<!-- Used for timestamps, so must fetch state. -->
<property name="fetchInMemoryState">true</property>
<!-- The max amount of time (in milliseconds) we wait until the
state (ie. the contents of the cache) are retrieved from
existing members at startup. Ignored if FetchInMemoryState=false. -->
<property name="stateRetrievalTimeout">60000</property>
<!-- Number of milliseconds to wait until all responses for a
synchronous call have been received. -->
<property name="syncReplTimeout">17500</property>
<!-- Max number of milliseconds to wait for a lock acquisition -->
<property name="lockAcquisitionTimeout">15000</property>
<!-- Hibernate 2LC can replicate custom types, so we use marshalling -->
<property name="useRegionBasedMarshalling">true</property>
<!-- Must match the value of "useRegionBasedMarshalling" -->
<property name="inactiveOnStartup">true</property>
<!-- Disable asynchronous RPC marshalling/sending -->
<property name="serializationExecutorPoolSize">0</property>
<!-- We have no asynchronous notification listeners -->
<property name="listenerAsyncPoolSize">0</property>
<property name="evictionConfig">
<bean class="org.jboss.cache.config.EvictionConfig">
<property name="wakeupInterval">5000</property>
<!-- Overall default -->
<property name="defaultEvictionRegionConfig">
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.LRUAlgorithmConfig">
<!-- Evict LRU node once we have more than this number of nodes -->
<property name="maxNodes">10000</property>
<!-- And, evict any node that hasn't been accessed in this many seconds -->
<property name="timeToLiveSeconds">1000</property>
<!-- Don't evict a node that's been accessed within this many seconds.
Set this to a value greater than your max expected transaction length. -->
<property name="minTimeToLiveSeconds">120</property>
</bean>
</property>
</bean>
</property>
<property name="evictionRegionConfigs">
<list>
<!-- Don't ever evict modification timestamps -->
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/TS</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.NullEvictionAlgorithmConfig"/>
</property>
</bean>
</list>
</property>
</bean>
</property>
</bean>
</value>
</entry>
<!-- A config appropriate for a cache that's shared for
entity, collection, query and timestamp caching. Not an advised
configuration, since it requires cache mode REPL_SYNC, which is the
least efficient mode. Also requires a full state transfer at startup,
which can be expensive. Uses optimistic locking -->
<entry><key>optimistic-shared</key>
<value>
<bean name="OptimisticSharedCache" class="org.jboss.cache.config.Configuration">
<!-- Node locking scheme -->
<property name="nodeLockingScheme">OPTIMISTIC</property>
<property name="useLockStriping">false</property>
<!-- Must use REPL since used for timestamp caching.
Must use SYNC to maintain cache coherency for entities. -->
<property name="cacheMode">REPL_SYNC</property>
<!-- Name of cluster. Needs to be the same for all members -->
<property name="clusterName">${jboss.partition.name:DefaultPartition}-opt-shared</property>
<!-- Use a UDP (multicast) based stack. Need JGroups flow control (FC)
because timestamp communication will not require a synchronous response. -->
<property name="multiplexerStack">${jboss.default.jgroups.stack:udp}</property>
<!-- Used for timestamps, so must fetch state. -->
<property name="fetchInMemoryState">true</property>
<!-- The max amount of time (in milliseconds) we wait until the
state (ie. the contents of the cache) are retrieved from
existing members at startup. Ignored if FetchInMemoryState=false. -->
<property name="stateRetrievalTimeout">60000</property>
<!-- Number of milliseconds to wait until all responses for a
synchronous call have been received. -->
<property name="syncReplTimeout">17500</property>
<!-- Max number of milliseconds to wait for a lock acquisition -->
<property name="lockAcquisitionTimeout">15000</property>
<!-- Hibernate 2LC can replicate custom types, so we use marshalling -->
<property name="useRegionBasedMarshalling">true</property>
<!-- Must match the value of "useRegionBasedMarshalling" -->
<property name="inactiveOnStartup">true</property>
<!-- Disable asynchronous RPC marshalling/sending -->
<property name="serializationExecutorPoolSize">0</property>
<!-- We have no asynchronous notification listeners -->
<property name="listenerAsyncPoolSize">0</property>
<property name="evictionConfig">
<bean class="org.jboss.cache.config.EvictionConfig">
<property name="wakeupInterval">5000</property>
<!-- Overall default -->
<property name="defaultEvictionRegionConfig">
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.LRUAlgorithmConfig">
<!-- Evict LRU node once we have more than this number of nodes -->
<property name="maxNodes">10000</property>
<!-- And, evict any node that hasn't been accessed in this many seconds -->
<property name="timeToLiveSeconds">1000</property>
<!-- Don't evict a node that's been accessed within this many seconds.
Set this to a value greater than your max expected transaction length. -->
<property name="minTimeToLiveSeconds">120</property>
</bean>
</property>
</bean>
</property>
<property name="evictionRegionConfigs">
<list>
<!-- Don't ever evict modification timestamps -->
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/TS</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.NullEvictionAlgorithmConfig"/>
</property>
</bean>
</list>
</property>
</bean>
</property>
</bean>
</value>
</entry>
<!-- A config appropriate for a cache that's shared for
entity, collection, query and timestamp caching. Not an advised
configuration, since it requires cache mode REPL_SYNC, which is the
least efficient mode. Also requires a full state transfer at startup,
which can be expensive. Uses pessmistic locking. -->
<entry><key>pessimistic-shared</key>
<value>
<bean name="PessimisticSharedCache" class="org.jboss.cache.config.Configuration">
<!-- Node locking scheme -->
<property name="nodeLockingScheme">PESSIMISTIC</property>
<!-- READ_COMMITTED is as strong as necessary for most
2nd Level Cache use cases. -->
<property name="isolationLevel">READ_COMMITTED</property>
<property name="useLockStriping">false</property>
<!-- Must use REPL since used for timestamp caching.
Must use SYNC to maintain cache coherency for entities. -->
<property name="cacheMode">REPL_SYNC</property>
<!-- Name of cluster. Needs to be the same for all members -->
<property name="clusterName">${jboss.partition.name:DefaultPartition}-pess-shared</property>
<!-- Use a UDP (multicast) based stack. Need JGroups flow control (FC)
because timestamp communication will not require a synchronous response. -->
<property name="multiplexerStack">${jboss.default.jgroups.stack:udp}</property>
<!-- Used for timestamps, so must fetch state. -->
<property name="fetchInMemoryState">true</property>
<!-- The max amount of time (in milliseconds) we wait until the
state (ie. the contents of the cache) are retrieved from
existing members at startup. Ignored if FetchInMemoryState=false. -->
<property name="stateRetrievalTimeout">60000</property>
<!-- Number of milliseconds to wait until all responses for a
synchronous call have been received. -->
<property name="syncReplTimeout">17500</property>
<!-- Max number of milliseconds to wait for a lock acquisition -->
<property name="lockAcquisitionTimeout">15000</property>
<!-- Hibernate 2LC can replicate custom types, so we use marshalling -->
<property name="useRegionBasedMarshalling">true</property>
<!-- Must match the value of "useRegionBasedMarshalling" -->
<property name="inactiveOnStartup">true</property>
<!-- Disable asynchronous RPC marshalling/sending -->
<property name="serializationExecutorPoolSize">0</property>
<!-- We have no asynchronous notification listeners -->
<property name="listenerAsyncPoolSize">0</property>
<property name="evictionConfig">
<bean class="org.jboss.cache.config.EvictionConfig">
<property name="wakeupInterval">5000</property>
<!-- Overall default -->
<property name="defaultEvictionRegionConfig">
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.LRUAlgorithmConfig">
<!-- Evict LRU node once we have more than this number of nodes -->
<property name="maxNodes">10000</property>
<!-- And, evict any node that hasn't been accessed in this many seconds -->
<property name="timeToLiveSeconds">1000</property>
<!-- Don't evict a node that's been accessed within this many seconds.
Set this to a value greater than your max expected transaction length. -->
<property name="minTimeToLiveSeconds">120</property>
</bean>
</property>
</bean>
</property>
<property name="evictionRegionConfigs">
<list>
<!-- Don't ever evict modification timestamps -->
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/TS</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.NullEvictionAlgorithmConfig"/>
</property>
</bean>
</list>
</property>
</bean>
</property>
</bean>
</value>
</entry>
<!-- Same as "mvcc-shared" but here we use REPEATABLE_READ
instead of READ_COMMITTED. REPEATABLE_READ is only useful if the
application evicts/clears entities from the Hibernate Session and
then expects to repeatably re-read them in the same transaction.
Otherwise, the Session's internal cache provides a repeatable-read
semantic. Before choosing this config, carefully read the docs
and make sure you really need REPEATABLE_READ. -->
<entry><key>mvcc-shared-repeatable</key>
<value>
<bean name="MVCCSharedRepeatableCache" class="org.jboss.cache.config.Configuration">
<!-- Node locking scheme -->
<property name="nodeLockingScheme">MVCC</property>
<!-- READ_COMMITTED is as strong as necessary for most
2nd Level Cache use cases. -->
<property name="isolationLevel">REPEATABLE_READ</property>
<property name="useLockStriping">false</property>
<!-- Must use REPL since used for timestamp caching.
Must use SYNC to maintain cache coherency for entities. -->
<property name="cacheMode">REPL_SYNC</property>
<!-- Name of cluster. Needs to be the same for all members -->
<property name="clusterName">${jboss.partition.name:DefaultPartition}-mvcc-shared-rr</property>
<!-- Use a UDP (multicast) based stack. Need JGroups flow control (FC)
because timestamp communication will not require a synchronous response. -->
<property name="multiplexerStack">${jboss.default.jgroups.stack:udp}</property>
<!-- Used for timestamps, so must fetch state. -->
<property name="fetchInMemoryState">true</property>
<!-- The max amount of time (in milliseconds) we wait until the
state (ie. the contents of the cache) are retrieved from
existing members at startup. Ignored if FetchInMemoryState=false. -->
<property name="stateRetrievalTimeout">60000</property>
<!-- Number of milliseconds to wait until all responses for a
synchronous call have been received. -->
<property name="syncReplTimeout">17500</property>
<!-- Max number of milliseconds to wait for a lock acquisition -->
<property name="lockAcquisitionTimeout">15000</property>
<!-- Hibernate 2LC can replicate custom types, so we use marshalling -->
<property name="useRegionBasedMarshalling">true</property>
<!-- Must match the value of "useRegionBasedMarshalling" -->
<property name="inactiveOnStartup">true</property>
<!-- Disable asynchronous RPC marshalling/sending -->
<property name="serializationExecutorPoolSize">0</property>
<!-- We have no asynchronous notification listeners -->
<property name="listenerAsyncPoolSize">0</property>
<property name="evictionConfig">
<bean class="org.jboss.cache.config.EvictionConfig">
<property name="wakeupInterval">5000</property>
<!-- Overall default -->
<property name="defaultEvictionRegionConfig">
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.LRUAlgorithmConfig">
<!-- Evict LRU node once we have more than this number of nodes -->
<property name="maxNodes">10000</property>
<!-- And, evict any node that hasn't been accessed in this many seconds -->
<property name="timeToLiveSeconds">1000</property>
<!-- Don't evict a node that's been accessed within this many seconds.
Set this to a value greater than your max expected transaction length. -->
<property name="minTimeToLiveSeconds">120</property>
</bean>
</property>
</bean>
</property>
<property name="evictionRegionConfigs">
<list>
<!-- Don't ever evict modification timestamps -->
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/TS</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.NullEvictionAlgorithmConfig"/>
</property>
</bean>
</list>
</property>
</bean>
</property>
</bean>
</value>
</entry>
<!-- Same as "pessimistic-shared" but here we use REPEATABLE_READ
instead of READ_COMMITTED. REPEATABLE_READ is only useful if the
application evicts/clears entities from the Hibernate Session and
then expects to repeatably re-read them in the same transaction.
Otherwise, the Session's internal cache provides a repeatable-read
semantic. Before choosing this config, carefully read the docs
and make sure you really need REPEATABLE_READ. -->
<entry><key>pessimistic-shared-repeatable</key>
<value>
<bean name="PessimisticSharedRepeatableCache" class="org.jboss.cache.config.Configuration">
<!-- Node locking scheme -->
<property name="nodeLockingScheme">PESSIMISTIC</property>
<property name="isolationLevel">REPEATABLE_READ</property>
<property name="useLockStriping">false</property>
<!-- Must use REPL since used for timestamp caching.
Must use SYNC to maintain cache coherency for entities. -->
<property name="cacheMode">REPL_SYNC</property>
<!-- Name of cluster. Needs to be the same for all members -->
<property name="clusterName">${jboss.partition.name:DefaultPartition}-pess-shared-rr</property>
<!-- Use a UDP (multicast) based stack. Need JGroups flow control (FC)
because timestamp communication will not require a synchronous response. -->
<property name="multiplexerStack">${jboss.default.jgroups.stack:udp}</property>
<!-- Used for timestamps, so must fetch state. -->
<property name="fetchInMemoryState">true</property>
<!-- The max amount of time (in milliseconds) we wait until the
state (ie. the contents of the cache) are retrieved from
existing members at startup. Ignored if FetchInMemoryState=false. -->
<property name="stateRetrievalTimeout">60000</property>
<!-- Number of milliseconds to wait until all responses for a
synchronous call have been received. -->
<property name="syncReplTimeout">17500</property>
<!-- Max number of milliseconds to wait for a lock acquisition -->
<property name="lockAcquisitionTimeout">15000</property>
<!-- Hibernate 2LC can replicate custom types, so we use marshalling -->
<property name="useRegionBasedMarshalling">true</property>
<!-- Must match the value of "useRegionBasedMarshalling" -->
<property name="inactiveOnStartup">true</property>
<!-- Disable asynchronous RPC marshalling/sending -->
<property name="serializationExecutorPoolSize">0</property>
<!-- We have no asynchronous notification listeners -->
<property name="listenerAsyncPoolSize">0</property>
<property name="evictionConfig">
<bean class="org.jboss.cache.config.EvictionConfig">
<property name="wakeupInterval">5000</property>
<!-- Overall default -->
<property name="defaultEvictionRegionConfig">
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.LRUAlgorithmConfig">
<!-- Evict LRU node once we have more than this number of nodes -->
<property name="maxNodes">10000</property>
<!-- And, evict any node that hasn't been accessed in this many seconds -->
<property name="timeToLiveSeconds">1000</property>
<!-- Don't evict a node that's been accessed within this many seconds.
Set this to a value greater than your max expected transaction length. -->
<property name="minTimeToLiveSeconds">120</property>
</bean>
</property>
</bean>
</property>
<property name="evictionRegionConfigs">
<list>
<!-- Don't ever evict modification timestamps -->
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/TS</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.NullEvictionAlgorithmConfig"/>
</property>
</bean>
</list>
</property>
</bean>
</property>
</bean>
</value>
</entry>
</map>
</property>
</bean>
</deployment>
在一个集群中JNDI是怎么工作的呢？
JBOSS Service 包含一个集群上
下文叫HA-JNDI(High Availability JNDI ).只要集群中有一个节点正常运行，集群就正常工作。
当一个远程客户端查找HA-JNDI时候，HA-JNDI将委托本地JNDI上下文，本地JNDI不能找到时候，
采用集群中范围内的JNDI对象。
HA-JNDI怎么配置的呢？
在JBOSS5.1 HA-JNDI的使用中 请求的服务器路径配置如下：
Properties prop = new Properties();
prop.setProperty("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
prop.setProperty("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");
prop.setProperty("java.naming.provider.url", "192.168.70.104:1099,192.168.45.146:1099");
try {
InitialContext ict = new InitialContext(prop);
HelloWorld helloWorld = (HelloWorld) ict.lookup("HelloWorld");
} catch (NamingException e) {
e.printStackTrace();
}
在jboss ejb3中无论是本地jndi还是HA-JNDi必须jboss client jar文件。
分别在IP地址为:192.168.70.104和192.168.45.146机器上面安装JBOSS5.1.0GA,安装的时候选择ejb3-clustered,再下面有一步时选择Advance,再在Name输入框输入all,其它默认就可以了。
/**
*
* <p>功能描述,该部分必须以中文句号结尾。<p>
*
* 创建日期 2013-5-28<br>
* @author longgangbai <br>
* @version $Revision$ $Date$
* @since 3.0.0
*/
public interface HelloWorld {
public String sayHello(String s);
}
/**
* 创建日期 2013-5-28<br>
* @author longgangbai<br>
* @version $Revision$ $Date$
* @since 3.0.0
*/
@Stateless(mappedName="HelloWorld")
@Clustered //HA-JNDI必须的配置
@Remote
public class HelloWorldBean implements HelloWorld {
public String sayHello(String s) {
System.out.println(s);
return s;
}
}
两台机器上面都安装好之后，分别在两台机器上面启动jboss,启动的时候需要加参数：如IP为192.168.70.104的机器启动JBOSS,则为：run -c all -b 192.168.70.104
当两台机器的JBOSS都正常启动后，将上面的Stateless Bean打包成jar包，发布到其中一台%JBOSS_HOME%\server\all\farm目录下面，这样集群中的其它结点将自动发布这个jar包。
客户端编写
斯蒂芬森
import java.util.Properties;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import com.easyway.cluster.HelloWorld;
/**
<p>
在JBOSS5.1 HA-JNDI的使用中 请求的服务器路径配置如下：
Properties prop = new Properties();
prop.setProperty("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
prop.setProperty("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");
prop.setProperty("java.naming.provider.url", "192.168.70.104:1099,192.168.45.146:1099");
</p>
*
* <p>功能描述,该部分必须以中文句号结尾。<p>
*
* 创建日期 2013-5-28<br>
* @author longgangbai<br>
* @version $Revision$ $Date$
* @since 3.0.0
*/
public class CLusterClient {
public static void main(String[] args) {
Properties prop = new Properties();
prop.setProperty("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
prop.setProperty("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");
prop.setProperty("java.naming.provider.url", "192.168.70.104:1099,192.168.45.146:1099");
try {
InitialContext ict = new InitialContext(prop);
HelloWorld helloWorld = (HelloWorld) ict.lookup("HelloWorld");
for (int i = 0; i < 100; i++) {
helloWorld.sayHello("HelloWorld");
}
} catch (NamingException e) {
e.printStackTrace();
}
}
}
在测试过程中可以停掉其中的一个jboss as 实例但是服务让然可以运行。
相关推荐
6. **配置文件**：在 JBoss 5.1 中，配置集群通常需要修改 `jboss-service.xml` 和 `jboss-web.xml` 文件。你需要添加集群相关的配置元素，例如指定集群名称、设置节点通信端口等。 7. **JNDI 查找**：在集群环境中...
在本案例中，"jboss-web.xml"、"jndi.properties"和"oracle-ds.xml"是针对EJB+JPA在JBoss应用服务器中的配置文件，它们各自承担着不同的职责。 首先，"jboss-web.xml"是JBoss特定的Web应用程序部署描述符，它是...
JBossTools是Red Hat公司开发的一系列开源插件，其目标是为开发者提供全面的支持，帮助他们在Java Enterprise Edition (Java EE) 平台上，特别是使用JBoss应用服务器时，能更高效地工作。JBossTools不仅限于Windows...
赠送jar包：jboss-logging-3.4.3.Final.jar； 赠送原API文档：jboss-logging-3.4.3.Final-javadoc.jar； 赠送源代码：jboss-logging-3.4.3.Final-sources.jar； 赠送Maven依赖信息文件：jboss-logging-3.4.3.Final....
在本课程测试代码中，我们将探讨如何在Eclipse集成开发环境（IDE）下使用Apache Ant构建工具，配合JBoss 5.1应用服务器进行EJB的开发和部署。 【Eclipse】是广泛使用的开源Java IDE，支持多种Java项目类型，包括EJB...
赠送jar包：jboss-logging-3.4.1.Final.jar； 赠送原API文档：jboss-logging-3.4.1.Final-javadoc.jar； 赠送源代码：jboss-logging-3.4.1.Final-sources.jar； 赠送Maven依赖信息文件：jboss-logging-3.4.1.Final....
"jboss-as-sprint-int-5.0.0.GA.jar" 和 "jboss-spring-int-vfs.jar" 是与JBoss应用服务器相关的两个关键组件，主要用于Spring框架与JBoss服务器的集成以及虚拟文件系统（Virtual File System，VFS）的支持。...
标题中的"jboss-as-sprint-int-5.0.0.GA.jar"和"jboss-spring-int-vfs.jar"就是这样的两个关键组件，用于帮助从Tomcat顺利过渡到JBoss环境。 首先，我们来详细了解一下`jboss-as-sprint-int-5.0.0.GA.jar`。这个...
赠送jar包：jboss-threads-3.1.0.Final.jar； 赠送原API文档：jboss-threads-3.1.0.Final-javadoc.jar； 赠送源代码：jboss-threads-3.1.0.Final-sources.jar； 赠送Maven依赖信息文件：jboss-threads-3.1.0.Final....
赠送jar包：jboss-annotations-api_1.3_spec-2.0.1.Final.jar； 赠送原API文档：jboss-annotations-api_1.3_spec-2.0.1.Final-javadoc.jar； 赠送源代码：jboss-annotations-api_1.3_spec-2.0.1.Final-sources.jar；...
官方离线安装包，亲测可用
在 JBOSS 的配置文件 war-deployers-jboss-beans.xml 中，我们需要打开 useJK 的配置，以便启用 JK 代理。 启动 JBOSS 启动 JBOSS，可以使用 run.bat 文件，该文件位于 JBOSS_HOME\bin 目录下。在启动 JBOSS 之后...
- **HA-JNDI客户端和自动发现**：客户端可以自动发现集群中的HA-JNDI服务。 #### 4. EJB集群 EJB（Enterprise JavaBeans）可以在JBoss集群中进行集群部署。 - **无状态会话Bean(Stateless Session Beans)**：适合于...
JdonFramework开源框架 v5.1 Build20071025_jdonframework-5.1 JdonFramework need above jdk 1.4.0 This version has passed under Tomcat 4.x/5.x JBoss 3.x/JBoss 4.0.0 Weblogic 8.1 when build this project ...
3. **配置session复制**：在JBoss的`jboss-service.xml`和`jboss-web.xml`中配置session复制相关的属性。 4. **配置集群通信**：设置JGroups，这是一个用于集群间通信的框架，用于节点间的健康检查和信息传递。 5. *...
本文是作者精心写作的完整配置搭建Jboss-5.1集群的文档,只要按照步骤来做绝对不会出错,一些重要部分俺还加以标注和详细说明,呕心沥血的一大完整安装文档.
赠送jar包：jboss-logging-3.3.2.Final.jar； 赠送原API文档：jboss-logging-3.3.2.Final-javadoc.jar； 赠送源代码：jboss-logging-3.3.2.Final-sources.jar； 赠送Maven依赖信息文件：jboss-logging-3.3.2.Final....
【标签】"开源项目"意味着dbDiff是一个公开源代码的软件，遵循特定的开源许可证，允许社区成员自由使用、修改和分发代码。开源项目的优点在于可以促进代码的透明度、创新和协作，同时也让全球的开发者有机会贡献自己...
复制操作完成后，该文件应放置于`D:\jboss-4.2.2.GA\server\default\deploy`目录下，等待进一步配置。 #### 步骤二：编辑MySQL数据源配置 打开`mysql-ds.xml`文件，进行必要的配置修改。配置内容包括： - **JNDI...