JBoss Cache as a POJO Cache
Pages: 1, 2, 3, 4, 5, 6

Brief JBoss Cache Overview

Plain Cache

The default plain cache module in JBoss Cache is called TreeCache. You can configure it either programmatically or through an external XML file. Here are the features that you can configure:

1. Cache mode: It can be either local or replicated. If it is replicated, you can further specify synchronous or asynchronous modes.
2. TransactionManager: You can specify a JTA-compliant transaction manager for JBoss Cache to look up. If it finds an ongoing transaction context, it will participate in that transaction and perform commit or rollback accordingly.
3. Pluggable eviction policy: The cache eviction policy refers to the algorithm the cache uses to expire its contents. In JBoss Cache, you can implement your own eviction policy via a pluggable interface. JBoss Cache currently ships with a region-based LRUEvictionPolicy.
4. Isolation level: JBoss Cache uses JDBC-style semantics for locking behavior. Instead of specifying read/write locks specifically, you can specify different isolation levels for ease of use.
5. Pluggable CacheLoader: CacheLoader allows you to load persisted cache contents back into the memory. JBoss Cache currently supports file loaders and SleepyCat- and JDBC-based loaders.
6. Overflowing: Combined with a cache loader and an eviction policy, this provides the passivation/activation feature seen in EJB. Whenever an item is evicted, it will be passivated so it is always persistent.

POJO Cache

The POJO cache module in JBoss Cache is called TreeCacheAop. In order to use the POJO cache, you have to "prepare" the objects (this process is also known as object instrumentation) before they are cached. This is needed so that the system can intercept the POJO operations. The object instrumentation process is performed by the JBoss AOP library. JBoss AOP allows you to specify the to-be-instrumented classes via an XML file or annotations. Currently, we support only JDK-1.4-style annotation (a specific feature of JBoss AOP). JDK 5.0 annotation support is coming in the next release and it will make the instrumentation process nearly transparent!

TreeCacheAop is a subclass of TreeCache, so it uses the same XML file for configuration and provides the same caching functionality as its superclass counterpart. The JBoss POJO Cache also has a POJO-based eviction policy.

A Use Case Walkthrough

In the rest of the article, we will use a "sensor network supervising system" example to illustrate the capability of JBoss POJO Cache in providing instantaneous fine-grained state replication and automatic preservation of state object relationship.

Problem Description

In the different stations along a high-speed railway, there are thousands of sensors that need to be monitored and supervised. Examples of such instruments include temperature, wind, and rain sensors that are critical to the successful operation of a high-speed train. If a particular sensor is malfunctioning, the manager computer in the supervising system should alert the administrator and shut down the unit and/or schedule it for maintenance.

Since the operation is mission-critical, the supervising system has to be highly available, meaning that whenever one sensor manager computer in the system goes down, the administrator should be able to seamlessly switch over to another one to perform supervision and active management. Hence, all manager computers must replicate the same sensor network state information at real time. Note that the characteristics of this kind of system--i.e., the requirement of high-availability and the existence of thousands (or even larger numbers) of elements--are also commonplace elsewhere in modern-day network management. Figure 2 illustrates the overview of such system that includes a clustering capability.

Figure 2. Overview of the sensor supervising system

Because of the hierarchical nature of the sensor network, a complicated domain object graph will typically be required to model the sensor network on the manager side. When the domain object states are not replicated (or persisted), management of object relationships (e.g., adding nodes and traversing the graph nodes) is provided by the JVM itself, and thus is transparent to the end user. However, because the Java serialization process does not recognize the object relationship, this seemingly simplistic object-graph relationship will break down when the states are either replicated or persisted. As a result, it renders a simple failover of the manager side components difficult to achieve.

Pages: 1, 2, 3, 4, 5, 6

Next Page