JBoss AS 4.x ships with JBoss Cache 1.4.x. To make use of new features, performance improvements and bug fixes in newer releases, you can follow some of the steps outlined onthis wiki page.

Yes. There are some scenarios where you may want to run multiple instances of JBoss Cache. For example, you want to run multiple local cache instances with each instance having its own configuration (e.g., different cache policy). In this case, you will need multiple xml configuration files.

Yes. Since Hibernate 3.0 release, you can configure it to use JBoss Cache as a second level cache. For details, see Hibernate documentation, and also see this wiki page.

JBoss Cache 3.x with MVCC in particular works very well as a Hibernate second level cache.

It is not necessary to use POJO Cache for second level cache inside Hibernate because Hibernate manages fine-grained fields in Java objects. Using POJO Cache won't provide any advantage, and will be an unnecessary performance drawback.

You can configure the JBoss Cache through a configuration xml file or programmatically using a org.jboss.cache.config.Configuration object, passed in to the org.jboss.cache.CacheFactory instance.

As of JBoss Cache 3.x, yes. An XSD schema is provided in your jbosscache-core.jar file, and is also available online, on http://www.jboss.org/jbosscache/jbosscache-config-3.0.xsd. You can configure your IDE, text editor or XML authoring tool to use this schema to validate your file.

JBossCache has five different cache modes, i.e., LOCAL , REPL_SYNC , REPL_ASYNC , INVALIDATION_SYNC and INVALIDATION_ASYNC . If you want to run JBoss Cache as a single instance, then you should set the cache mode to LOCAL so that it won't attempt to replicate anything. If you want to have synchronous replication among different JBoss Cache instances, you set it to REPL_SYNC . For asynchronous replication, use AYSNC_REPL . If you do not wish to replicate cached data but simply inform other caches in a cluster that data under specific addresses are now stale and should be evicted from memory, use INVALIDATION_SYNC or INVALIDTAION_ASYNC . Synchronous and asynchronous behavior applies to invalidation as well as replication.

Note that ASYNC_REPL and INVALIDATION_ASYNC are non-blocking. This can be useful when you want to have another JBoss Cache serving as a mirror or backup and you don't want to wait for confirmation that this mirror has received your messages.

JBoss Cache leverages JGroups for network communications. A JGroups configuration section is present in your JBoss Cache configuration.

A user can configure the cluster of JBoss Cache instances by sharing the same cluster name ( cluster name ). There is also an option of whether to populate the cache data upon starting a new instance in the ClusterConfig attribute.

Note that once all instances join the same replication group, every replication change is propagated to all participating members. There is no mechanism for sub-partitioning where some replication can be done within only a subset of members, unless you use the Buddy Replication features. See the Users' Guide for more details on this.

Yes, both will continue to run, but depending on your replication mode, all transactions or operations may not complete. If REPL_SYNC is used, operations will fail while if REPL_ASYNC is used they will succeed. Even if they succeed though, caches will be out of sync.

At this stage the answer is no. We do have an abstraction layer between the communication suite and JBoss Cache in the pipelines, and this may appear as a feature at some stage in the future.

Replication need not occur to every node in the cluster. This feature - called Buddy Replication - allows each node to pick one or more 'buddies' in the cluster and only replicate to its buddies. This allows a cluster to scale very easily with no extra impact on memory or network traffic with each node added.

See the Users' Guide for more information on Buddy Replication, and how it can be used to achieve very high scalability.

Session affinity relates to returning to the same cache instance for the same data being used. While this is strictly not a requirement for Buddy Replication, it is greatly recommended to minimize moving state around a cluster.

Yes. All the above mentioned properties are per cache instance. Therefore you will need separate org.jboss.cache.Cache instances.

Yes, it can be. For such cases it is recommended that you configure your cache using the JGroups Multiplexer, which allows several caches to share a single JGroups channel. Please see the Users' Guide for details on how to configure the JGroups Multiplexer.

A faster and more efficient approach is to use a shared transport in JGroups. Please see the JGroups documentation for more details on how to do this.

Yes. They are both JGroups group names. Besides the notion of a channel in JGroups, it also can partition the channel into different group names.

There are two parameters to consider: multicast address (plus port) and the group name. At minimum, you will have to run components using a different group name. But whether to run them on the same channel depends upon whether the communication performance is critical for you or not. If it is, then it'd be best to run them on different channels.

Yes. JBoss Cache has a cache loader interface that supports cache persistence. See below for more FAQs on cache loaders.

Yes. JBoss Cache uses the cache loader to support cache passivation/ overflow. See documentation on how to configure and use this feature.

Yes, it is thread safe.

No, although it is also on our to do list. Our internal implementation does use a procedure similar to 2PC to coordinate a transactions among different instances, but JBoss Cache is not an XA resource.

JBoss Cache supports any TransactionManager that is JTA compliant such asJBoss Transactions.

While JBoss Cache does ships with a dummy transaction manager (org.jboss.cache.transaction.DummyTransactionManager), we do not recommend using this for production. It is not thread safe, and is intended for internal testing only.

You either use the default transaction manager that ships with JBoss AS or you have to implement the org.jboss.cache.transaction.TransactionManagerLookup interface, and return an instance of your javax.transaction.TransactionManager implementation. The configuration property TransactionManagerLookupClass defines the class to be used by the cache to fetch a reference to a transaction manager. It is trivial to implement this interface to support other transaction managers. Once this attribute is specified, the cache will look up the transaction context from this transaction manager.

The org.jboss.cache.transaction.GenericTransactionManagerLookup class that ships with JBoss Cache is able to detect and bind to most popular transaction managers. See the GenericTransactionManagerLookup javadocs for more information.

JBoss Cache lets you control the cache locking level through the transaction isolation level. This is configured through the attribute IsolationLevel . The transaction isolation levels correspond to database isolation levels, namely, NONE , READ_UNCOMMITTED , READ_COMMITTED , REPEATABLE_READ , and SERIALIZABLE . Note that these isolation levels are ignored if optimistic locking is used. For details, please refer to the user manual.

As of JBoss Cache 3.x, when using the MVCC locking scheme, only READ_COMMITTED and REPEATABLE_READ are supported. Any other isolation level provided will either be upgraded or downgraded accordingly.

In JBoss Cache 2.x, by default pessimistic locking is used to lock data nodes, based on the isolation level configured. We also offer optimistic locking to allow for greater concurrency at the cost of slight processing overhead and performance. See the documentation for a more detailed discussion on concurrency and locking in JBoss Cache.

In JBoss Cache 3.x, optimistic and pessimistic locking are deprecated in favour of MVCC (multi-version concurrency control), which is far more efficient than either optimistic or pessimistic locking. For a detailed discussion on our MVCC implementation, see this blog entry andthis wiki page.

Please see the configuration section of the Users' Guide for details.

Yes. JBoss Cache controls the individual node locking behavior through the isolation level semantics. This means even if you don't use a transaction, you can specify the lock level via isolation level. You can think of the node locking behavior outside of a transaction as if it is under transaction with auto_commit on.

Yes, but this is is only possible if you are running within a JTA transaction and are using either MVCC or PESSIMISTIC as your node locking scheme.

To achieve SELECT FOR UPDATE semantics, simply do:

    // start transaction ... 


    cache.getInvocationContext().getOptionOverrides().setForceWriteLock(true);

    Node n = cache.get("/a/b/c"); // this acquires a WRITE LOCK on this node

        ...

        ...


    // end transaction


                    

If the updates are under transaction, then the broadcasts happen only when the transaction is about to commit (actually during the prepare stage internally). That is, it will be a batch update. However, if the operations are not under transaction context, then each update will trigger replication. Note that this has performance implications if network latency is a problem.

If you do acache.removeNode("/myroot"), it will recursively remove all the entries under "/myroot".

Yes, using a JMX console such as the one shipped with JBoss AS or Java 5's jconsole utility. See the chapter titled Management Information in the JBoss Cache Users' Guide for more details.

This is something we have seen with some MBean servers. By default, JBoss Cache uses jboss.cache:service=JBossCache as a prefix to all objects it binds in JMX. To work around this, use the -Djbosscache.jmx.prefix JVM parameter to pass in an alternate prefix.

Yes, you can. See the section on configuration in the JBoss Cache Users' Guide.

As of JBoss Cache 2.0.0, the dependency on JBoss Serialization has been dropped since most of the benefits of JBoss Serialization are available in updated Java 5 VMs. Since JBoss Cache 2.0.0 is baselined on Java 5, there was no need to provide these benefits separately.

Not right now. JBoss Cache does not support partitioning that a user can configure to have different set of data residing on different cache instances while still participating as a replication group.

This is on the roadmap though, so do keep an eye on JBCACHE-60 if you are interested.

Application-specific classloading is used widely inside a Java EE container. For example, a web application may require a new classloader to scope a specific version of the user library. However, by default JBoss Cache is agnostic to the classloader. In general, this leads to two kinds of problems:

To solve the first kind of issue JBoss Cache uses a CacheMarshaller . Basically, this allows application code to register a classloader with a portion of the cache tree for use in handling objects replicated to that portion. See the CacheMarshaller section of the Users' Guide for more details.

To solve the second kind of issue, you can use the the UseLazyDeserialization configuration option in JBoss Cache, which wraps your objects in a Marshalledvalue wrapper. The MarshalledValue serializes and deserializes your object on demand, ensuring the proper thread local context class loader is used each time.

Yes. A boolean is passed in to each notification callback identifying whether the callback is before or after the event. See the org.jboss.cache.notifications.annotations.CacheListener annotation for details.

See the Users' Guide on this subject.

Yes, you can. Originally, cache Marshalling was designed as a workaround for those replicated caches that upon state transfer did not have access to the classloaders defining the objects in the cache.

On each deployment, JBoss creates a new classloader per the top level deployment artifact, for example an EAR. You also have to bear in mind that a class in an application server is defined not only by the class name but also its classloader. So, assuming that the cache is not deployed as part of your deployment, you could deploy an application and put instances of classes belonging to this deployment inside the cache. If you did a redeployment and try to do a get operation of the data previously put, this would result on a ClassCastException. This is because even though the class names are the same, the class definitions are not. The current classloader is different to the one when the classes were originally put.

By enabling marshalling, you can control the lifecycle of the data in the cache and if on undeployment, you deactivate the region and unregister the classloader that you'd have registered on deployment, you'd evict the data in the cache locally. That means that in the next deployment, the data won't be in the cache, therefore avoiding the problem. Obviously, using marshalling to get around this problem is only recommended when you have some kind of persistence backing where the data survives, for example using CacheLoaders, or when JBoss Cache is used as a second level cache in a persistence framework.

To implement this feature, please follow the instructions indicated in the example located in the CacheMarshaller section of the Users' Guide. It's worth noting that instead of a ServletContextListener , you could add this code into an MBean that contained lifecycle methods, such as start() and stop() . The key would be for this MBean to depend on the target cache, so that it can operate as long as the cache is up and running.