Open Source Java Community and OpenJDK Resources. Latest News, podcasts, Updates, downloads.

OSCache is a caching solution that includes a JSP tag library and set of classes to perform fine grained dynamic caching of JSP content, servlet responses or arbitrary objects. It provides both in memory and persistent on disk caches, and can allow your site to have graceful error tolerance (eg if an error occurs like your db goes down, you can serve the cached content so people can still surf the site almost without knowing). Take a look at the great features of OSCache.

OSCache Features

Fast in-memory caching

* OSCache allows you to store dynamic content (eg for 30 minutes) in memory. Each further request is served directly from the memory cache, resulting in dramatic speed increases.
* The cache is keyed programmatically. This means you can calculate a cache key that works for your situation. For example an ecommerce site might use product ID as keys, or content site might use an article date and article ID combination.
* The cache is stored in standard scopes that any JSP programmer is familiar with (application or session). The session scope allows you to have different cached content per user. This is one unlike any other caching system we've ever seen.

Persistent on-disk caching

* OSCache can also write the cache to disk. This provides caching across server restarts, and caching of datasets that do not fit into memory. Caching can be configured to use memory or file caching, or a combination of both.
* If you want to persist the cache to somewhere other than disk, you can plug in a custom PersistenceListener. This allows you to persist the cache to anywhere (for example to a database via JDBC or to LDAP via JNDI).
* When using both disk caching and memory caching. It is possible to limit the cache size to avoid using too much memory but let disk cache unlimited, resulting in browser style complementary disk cache. When cached objects are removed from memory, they are still on disk. If the item is needed again and it is not expired the cache file will be used. This also gives fault tolerance if the server crashes.
* Persistence can also be switched to overflow mode using the property oscache.persistence.overflow.only. This changes the default behavior (of persisting every cache entry when there is a listener) to only persist when the memory cache capacity has been reached.

Excellent Performance

* Written with performance in mind.
* Mulitple cache requests can be handled concurrently.
* Only one requesting thread needs to update an expired cache entry even if multiple threads are requesting it simultaneously. Other threads can be configured to either receive the recently-expired object, or block until the cached object is updated. Similarly, when a new entry is being added to the cache, other threads requesting that entry will block until it is ready rather than run off and race to build the same object. In a high load environment this can provide enormous performance benefits.
* Automatically takes advantage of JRE 1.4 or higher if available.

Clustering support

* OSCache can easily be configured to cluster across multiple boxes. This provides both scalability and failover support without any changes required in your caching code.

Flexible Caching System

* OSCache allows you to cache portions of JSP pages, arbitrary Java objects, and even entire servlet responses.
* Cache capacity can be set allowing you to limit the number of cached objects.
* Multiple caching algorithms are supported such as LRU (Least Recently Used), FIFO (First In First Out), or unlimited. It is also possible to plug in your own custom algorithm.
* You are given a huge amount of control over the way cached objects expire. Objects can be cached indefinitely, expired once they reach a certain age, or expired based on a cron expression. Programmatic flushing is also possible, and if that is still not enough pluggable RefreshPolicies allow custom refresh strategies.
* Cached objects can be grouped together however you like, allowing for powerful management of cached data. This is an extremely useful feature that is far more powerful than what other caching solutions typically offer (such as the flushing of cache keys that match a particular pattern).
* Fully event driven! OSCache fires events for various happenings 'under the hood' such as cache entry events (adding, updating, flushing and removing) and cache accesses (hit, stale hit and miss). It is easy to add your own event handlers.
* Multiple caches can be created, each with their own unique configuration.

Simple JSP Tag Library

* The tag library to perform and control the caching is very simple. See the Tag Reference for more information.

Caching Filter

* A Servlet 2.3 Filter allows for caching of entire pages and generated binary files (like dynamically created images or PDF files).
* Caching of binary files is extremely useful when they are generated dynamically and the average creation time is long.
* The CacheFilter is using the last modified header to reduce excellently the transaction overhead and server load which speed ups the server response time.

Comprehensive API

* For the ultimate control, OSCache can be used through its straightforward API. You can instantiate, configure and control multiple caches programmatically. It would be possible for example to create one small in-memory cache that held currency conversion rates and was updated daily at 2am, while another cache could be purely disk based and used for holding dynamically created images.

Exception Handling

* OSCache provides a way for your site to gracefully tolerate errors. This is not error prevention, rather if an error occurs it should not stop your site from functioning. For example if your database goes down, normally your product descriptions will not be browsable. Using OSCache you can cache those descriptions so you can still browse them.

Cache Flushing

* Flushing of caches can be controlled via JSP Tags, so these functions can easily be built into your administration interface.
* There is programmatic control over what caches are flushed (eg all caches or just a particular scope).
* Cached objects can be expired in a number of ways. Objects can be told to expire once they reach a certain age, or, through the use of cron expressions, on particular dates and/or times (eg it is trivial to make an object expire every weekday at 3am). If this is not enough, you can expire objects programmatically as required, or plug in your own custom RefreshPolicy class that can dynamically decide when an object should be flushed.
* Entire groups of objects can be easily flushed from the cache. For example suppose you were caching product data as well as entire pages of your website. When a product was updated, you could flush not just the product object but also all the pages that contain information about that product. No more waiting for the cached objects to expire before the updated content shows up on your site!

Portable caching

* Pure Java, this means it is platform independent.
* OSCache is compliant with Servlet 2.3 and JSP 1.2 standards, which means it should work in the latest generation of servlet containers and application servers.

i18n Aware

* The caching is i18n aware and supports all encodings.

Solid Reputation

* Thousands of downloads, hundreds of users on the mailing list.
* Comprehensive JUnit test suite that covers every aspect of OSCache, including a web stress test and various concurrent cache access scenarios. To back this up, the kind folks at Cortex have supplied us with a Clover license to provide detailed code coverage analysis of our unit tests.
* We have solid issue tracking using JIRA to keep track of any feature requests, bug reports and development progress. JIRA is provided courtesy of Atlassian.

Project Home Page
http://www.opensymphony.com/oscache/

Documentation
http://www.opensymphony.com/oscache/wiki/Documentation.html

Java API Documentation
http://www.opensymphony.com/oscache/api/index.html

JCS is a distributed caching system written in java. It is intended to speed up applications by providing a means to manage cached data of various dynamic natures. Like any caching system, JCS is most useful for high read, low put applications. Latency times drop sharply and bottlenecks move away from the database in an effectively cached system. Learn how to start using JCS.

The JCS goes beyond simply caching objects in memory. It provides numerous additional features:

* Memory management
* Disk overflow (and defragmentation)
* Thread pool controls
* Element grouping
* Minimal dependencies
* Quick nested categorical removal
* Data expiration (idle time and max life)
* Extensible framework
* Fully configurable runtime parameters
* Region data separation and configuration
* Fine grained element configuration options
* Remote synchronization
* Remote store recovery
* Non-blocking "zombie" (balking facade) pattern
* Lateral distribution of elements via HTTP, TCP, or UDP
* UDP Discovery of other caches
* Element event handling
* Remote server chaining (or clustering) and failover

JCS works on JDK versions 1.3 and up. It only has two dependencies: Commons Logging and Doug Lea's Util Concurrent.

The foundation of JCS is the Composite Cache, which is the pluggable controller for a cache region. Four types of caches can be plugged into the Composite Cache for any given region: (1) Memory, (2) Disk, (3) Lateral, and (4) Remote. The Composite Cache orchestrates access to the various caches configured for use in a region.

The JCS jar provides production ready implementations of each of the four types of caches. In addtion to the core four, JCS also provides additional plugins of each type.

The LRU Memory Cache is an extremely fast, highly configurable memory cache . It uses a Least Recently Used algorithm to manage the number of items that can be stored in memory. The LRU Memory Cache uses its own LRU Map implementation that is significantly faster than both the commons LRUMap implementation and the LinkedHashMap that is provided with JDK1.4 up. This makes JCS faster than its competitors .

The Indexed Disk Cache is a fast, reliable, and highly configurable swap for cached data. The indexed disk cache follows the fastest pattern for disk swapping. Cache elements are written to disk via a continuous queue-based process. The length of the item is stored in the first few bytes of the entry. The offset is stored in memory and can be reference via the key. When items are removed from the disk cache, the location and size are recorded and reused when possible. Every aspect of the disk cache is configurable, and a thread pool can be used to reduce the number of queue worker threads across the system.

JCS is not a tag library or a web specific application. JCS is a general purpose caching system that can be used in web applications, services, and stand alone Java applications.

JCS is not a transactional distribution mechanism. Transactional distributed caches are not scalable. JCS is a cache not a database. The distribution mechanisms provided by JCS can scale into the tens of servers. In a well-designed service oriented architecture, JCS can be used in a high demand service with numerous nodes. This would not be possible is the distribution mechanism were transactional.

JCS does not use AOP. JCS is a high performance, non-invasive cache. It does not manipulate your objects so it can just send a field or two fewer over the wire.

JCS is not fork, an offshoot, a branch, or any other derivation of JCS. Nor is JCS named after another library. JCS is a mature project that has been under development and in use since 2001. Over the years JCS has encorporated numerous bug fixes and has added dozens of features, making it the best designed and most feature rich caching solution available.

Project Home Page
http://jakarta.apache.org/turbine/jcs/

JCS Download
http://jakarta.apache.org/jcs/DownloadPage.html

Ehcache is a widely used java distributed cache for general purpose caching, JEE and light-weight containers.

It features memory and disk stores, replicate by copy and invalidate, listeners, a gzip caching servlet filter and much more...

Ehcache is available under an Apache open source license and is actively developed, maintained and supported.

Features of Ehcache

* Fast and Light Weight
o Fast
o Simple
o Small foot print
o Minimal dependencies
* Scalable
o Provides Memory and Disk stores for scalabilty into gigabytes
o Scalable to hundreds of caches
o Tuned for high concurrent load on large multi-cpu servers
o Multiple CacheManagers per virtual machine
* Complete
o Supports Object or Serializable caching
o Support cache-wide or Element-based expiry policies
o Provides LRU, LFU and FIFO cache eviction policies
o Provides Memory and Disk stores
o Distributed Caching
* Standards Based
o Full implementation of JSR107 JCACHE API
* Extensible
o Listeners may be plugged in
o Peer Discovery, Replicators and Listeners may be plugged in
* Application Persistence
o Persistent disk store which stores data between VM restarts
o Flush to disk on demand
* Supports Listeners
o CacheManager listeners
o Cache event listeners
* JMX Enabled
* Distributed
o Peer Discovery
o Reliable Delivery
o Synchronous Or Asynchronous Replication
o Copy Or Invalidate Replication
o Transparent Replication
o Extensible
o Bootstrapping from Peers
* JEE and Applied Caching
o Blocking Cache to avoid duplicate processing for concurrent operations
o SelfPopulating Cache for pull through caching of expensive operations
o JEE Gzipping Servlet Filter
o Cacheable Commands
o Works with Hibernate
* High Quality
o High Test Coverage
o Automated Load, Limit and Performance System Tests
o Production tested
o Fully documented
o Trusted by Popular Frameworks
o Conservative Commit policy
o Full public information on the history of every bug
o Responsiveness to serious bugs
* Open Source Licensing
o Apache 2.0 license

Project Home Page
http://ehcache.sourceforge.net/

FKache Open Source is an effort to make an Open Source version of JSR-107 FKache. Since the JSR-107 hasn&t released any specs for years, This version still builds on the original Functional Specification.

JSR 107 has started seeding some of the works. A Draft API has been released at: jsr-107 interest project at java.net. I have started deprecating and refactoring my project to make it an implementation of this draft API. This will be dome in several iterations, so you get a chance to change your code. For each iteration, all methods/classes/packages changed or removed is deprecated. So you only need to find all deprecated methods/classes in FKache, and replace them with the proposed replacement. I the deprecation is marked with "no replacement", and you are using that feature, please contact me to see if a solution can be made available.

Project Home Page
http://jcache.sourceforge.net

Download JCache
http://sourceforge.net/project/showfiles.php?group_id=66335

FKache Documentation
http://jcache.sourceforge.net/documentation/index.html

ShiftOne Java Object Cache is a Java library that implements several strict object caching policies, decorators that add behavior, and a light framework for configuring them for an application.

It's strict in that each cache enforces two limits in a very strict and predictable way.
# Max Size - each cache has a hard limit on the number of elements it will contain. When this limit is exceeded, the least valuable element is evicted. This happens immediately, on the same thread. This prevents the cache from growing uncontrollably
# Element Timeout - each cache has a maximum time that it's elements are considered valid. No element will ever be returned that exceeds this time limit. This ensures a predictable data freshness.

Currently, First In First Out (fifo), Least Recently Used (lru), and Least Frequently Used (lfu) caching policies are implemented. These are refered to as policy caches. They are responcible for holding onto the data in the cache.

ShiftOne Features

Features are added by wrapping policy caches with "decorators". When a decorator is configured for a cache, your application operates on the decorator cache, which delegates to a policy cache. Behavior is configured by linking several decorators in front of a policy cache.

Support includes:
# Monitoring and instrumentation with JMX
# Clustering using JGroups or JMS
# Hit/Miss statistics reporting
# Memory sensitivity using soft references
# Hibernate ORM integration (adaptor)

There are also a number of adaptors that allows a cache to take on another interface.

How is a cache obtained?

This cache implementation strives to abstract from an application, the concrete implementation and configuration of a cache. For this reason, cache's should be accessed exclusively using the "Cache" interface (cache policies are not public classes, so this is required).

Both caches and cache factories may be obtained from a cache configuration. A cache configuration allows mnemonic names to be associated with various cache and factory configurations.

If an application absolutely needs to programmatically set the max size and timeout of a cache, then a cache factory should be obtained from the config first, and used to create a cache.

Why was this implemented?

JOCache was originally implemented as part of the ExQ project to support ResultSet caching. It was later split out for use by other projects. It was designed to cache large expensive database query results.

ShiftOne Project Home Page
http://jocache.sourceforge.net/

Download ShiftOne
http://sourceforge.net/project/showfiles.php?group_id=67753

ShiftOne API Documentation
http://jocache.sourceforge.net/api/index.html

SwarmCache is a simple but effective distributed cache. It uses IP multicast to efficiently communicate with any number of hosts on a LAN. It is specifically designed for use by clustered, database-driven web applications. Such applications typically have many more read operations than write operations, which allows SwarmCache to deliver the greatest performance gains. SwarmCache uses Java Community internally to manage the membership and communications of its distributed cache.

Wrappers have been written that allow SwarmCache to be used with the Hibernate and JPOX persistence engines.

How It Works?
The concept behind SwarmCache is fairly simple. Each server instantiates its own manager. For each type of object that the server wishes to cache, it instantiates a cache and adds it to the manager. The manager joins a multicast group and communicates with other managers in the group. Whenever an object is removed from a cache, the manager notifies all other managers in the group. Those managers then ensure that the object is removed from their respective caches. The result is that a server will not have in its cache a stale version of an object that has been updated or deleted on another server.

Note that the managers only need to communicate when an object is removed from a cache. This only happens when an object is updated or deleted. The managers do not co-operate beyond this. This means that the amount of inter-server communications is proportional to the amount of updates/deletes of the application. As the communications is multicast, it is not proportional to the number of caching hosts. Also notice that there is no "server"; all hosts are equal peers and they can come and go from the cache group as they please without affecting other group members. Thus the operation of the distributed cache is very robust.

Basic Usage
SwarmCache is designed to be integrated in to the persistence layer of a database-driven Java application. However, it could be useful for other types of applications. Once built in to the persistence engine, SwarmCache should be transparent to higher layers of the software. SwarmCache does not directly support transaction management. This can be accomplished by wrapping the cached objects and storing some additional transaction data. This will described and possibly implemented at a later date.

Swarmcache requires that swarmcache.jar, jgroups-all.jar, commons-collections.jar, and commons-logging.jar (included in the download) be in your classpath.

For most applications, it is sufficient to make use of the CacheFactory class to configure and use SwarmCache. Here is an example:

import net.sf.swarmcache.*;

...

CacheFactory cacheFactory;

...

// Configure and Initialize the cache manager
CacheConfiguration conf = new CacheConfiguration();
conf.setCacheType(CacheConfiguration.TYPE_LRU);
cacheFactory = new CacheFactory(conf);

...

// Create a new cache, using a name that describes
// what kind of object we will store
ObjectCache cache = cacheFactory.createCache("People");

...

// Store something in the cache
String key = "0001";
String person = "John Watkinson";
cache.put(key, person);

...

// Retrieve something from the cache
String person = (String)cache.get("0001");
System.out.println(person);

...

// Clear an object from the cache
// (This results in the sending of a
// multicast message to other caching hosts)
cache.clear("0001");
String person = (String)cache.get("0001");
// The following will print 'null'
System.out.println(person);

The example is simple, but running this same code on multiple machines in a network will result in their caches being consistent.

Note that the keys used must be serializable objects-- they must implement java.io.Serializable. The objects themselves that are stored in the cache need not be serializable. And of course, the keys should not be large objects for transmission efficiency purposes.

In order to keep keys distinct, it is usually preferred to have one cache per type of object stored. In that case, it makes sense to follow the convention that the cache be named after the fully-qualified class name of the object type to be stored.

Usage in a Persistence Engine

Here is some skeleton code that demonstrates how SwarmCache could be integrated in to a persistence engine. The following class is responsible for persisting an object of type Person:

public class PersonEntity extends GenericEntity {

...

public Person get(long key) {
Long cacheKey = new Long(key);
Person person = (Person)cache.get(cachekey);
if (person == null) {
// * Get the object from the database
if (person != null) {
// Put it in the cache
cache.put(cacheKey, person);
}
}
return person;
}

...

public void insert(Person person) {
// * Do database insert
// Add new object to cache
Long cacheKey = new Long(person.getKey());
cache.put(cacheKey, person);
}

...

public void update(Person person) {
// * Do database update
// Remove object from cache
// (This causes all caches in the group to be notified)
Long cacheKey = new Long(person.getKey());
cache.clear(cacheKey);
// Re-add the object to the cache
cache.put(cacheKey, person);
}

...

public void delete(long key) {
// * Do database delete
// Remove object from cache
// (This causes all caches in the group to be notified)
Long cacheKey = new Long(key);
cache.clear(cacheKey);
}

...

}


SwarmCache Project Home Page
http://swarmcache.sourceforge.net

SwarmCache Documentation
http://swarmcache.sourceforge.net/documentation.html

Download SwarmCache
http://sourceforge.net/project/showfiles.php?group_id=78637&release_id=193220

Permalink

JBoss Cache is a replicated and transactional cache. It is replicated since multiple JBoss Cache instances can be distributed (either within the same JVM or across several JVMs whether they reside on the same machine or on different machines on a network) and data is replicated across the whole group. It is transactional because a user can configure a JTA compliant transaction manager and make the cache operation transactional. Note that the cache can also be run without any replication; this is the local mode.

Currently, JBoss Cache consists of two components: a generic cache (implemented internally as org.jboss.cache.TreeCache) and a POJO cache (implemented internally as org.jboss.cache.aop.PojoCache). TreeCache is a tree-structured cache that provides replication and transaction context, while PojoCache extends the functionality of TreeCache but behaves as a true object cache providing transparent and finer-grained object mapping into internal cache.

JBoss Cache is a product designed to cache frequently accessed Java objects in order to dramatically improve the performance of e-business applications. By eliminating unnecessary database access, JBoss Cache decreases network traffic and increases the scalability of applications.

But JBoss Cache is much more than a simple cache. JBoss Cache provides fully transactional features as well as a highly configurable set of options to deal with concurrent data access in the most efficient manner possible for your application. In addition, it is a clustered cache that replicates contents to other cache instances running on separate JVMs, servers or even entire networks, making JBoss Cache a highly efficient library used by application server developers to implement clustering features.

JBoss Cache provides two caching APIs to suit your needs. The JBoss Cache API offers a traditional, tree-structured, node-based cache and the Pojo Cache API, which builds on the JBoss Cache API, provides the ability to perform object-based, fine-grained replication of Java objects, resulting in maximum performance benefits. Please see the JBoss Cache user guide for a more detailed discussion on these APIs.

What is the license for JBoss Cache?

JBoss Cache is licensed under LGPL

How do I build JBoss Cache from CVS sources?

To build, do sh build.sh jar. This will produce jboss-cache.jar in the dist/lib directory. Or if you want to build the standalone package, do sh build.sh dist this will produce dist/jboss-cache-dist.zip Note that you will need to use JDK 5.0 to build the distribution. You can still use the binaries you build with J2SE 1.4.x though..

Can I run JBoss Cache outside of JBoss Application Server?

Of course! JBoss Cache comes in two flavors:
* Integrated with JBoss Application Server as an MBean service.
* Standalone, that can run in any Java EE server such as BEA WebLogic or IBM Websphere. Of course, it can also run in a standalone Java process (i.e., outside Java EE context).

How do I deploy JBoss Cache as a MBean service?

To deploy JBoss Cache as an MBean inside JBoss, you can copy the configuration xml file over to the deploy directory (from all configuration whereby the necessary jars are present). Under the standalone package etc/META-INF directory , there are example configuration files for different cache modes that can be used to deploy JBoss Cache as well.

How does JBoss Cache's replication mechanism work?

JBoss Cache leverages JGroups as a replication layer. 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. This is on our to do list.

Which TransactionManagers are supported by JBoss Cache?

JBoss Cache supports any TransactionManager that is JTA compliant such as JBossTM. A user can configure the transaction manager through the configuration xml setting. JBossCache also has a built in dummy transaction manager (org.jboss.cache.tm.DummyTransactionManager) for testing purposes only. But note that DummyTransactionManager is not thread safe .i.e., it does not support concurrent transactions. Instead, only one transaction is allowed at a time.

Download JBoss Cache
http://labs.jboss.com/jbosscache/download/index.html

JBoss Cache Documentation
http://labs.jboss.com/jbosscache/docs/index.html

Whirlycache is a fast, configurable in-memory object cache java. It can be used, for example, to speed up a website or an application by caching objects that would otherwise have to be created by querying a database or by another expensive procedure. From the testing that we have done, it appears to be faster than any other Java cache that we have been able to inspect.

Whirlycache Benchmark Results.

Whirlycache Design

Whirlycache is built around several design principles that differ from other cache implementations:

1. Require synchronization as infrequently as possible
2. Do as little as possible in the insertion and retrieval operations
3. Soft limits are acceptable for many applications
4. Disk overflow becomes a bad idea very quickly

Many attributes of Whirlycache are configurable in an XML file, but the most important components of the cache are the Backend, the Tuner, and the Policy.

We support pluggable backend implementations that need to implement the ManagedCache interface (which is a subinterface of java.util.Map, although not all the methods of Map need to be implemented). We currently support two backends: ConcurrentHashMap and FastHashMap. You can decide which one suits your application best. In our testing, it's hard to tell which one comes out on top all of the time. If you need to, you can even implement your own backed by implementing the ManagedCache interface.

The Tuner is a background thread that performs cache maintenance activites specified in the configured Policy implementation. One Tuner thread per cache is created and it is configured to run every n seconds. It depends on your application, but you definitely don't want to run the Tuner too often since it will only serve to burden the system unnecessarily. If your data doesn't change a lot, you could simply configure it to run every few minutes.

The purpose of the Tuner is to perform activities that would otherwise be performed by the insertion and retrieval operations (which we want to keep very lean and fast). The Tuner expires elements from the cache based on the configured Policy and the configured maxsize of the cache. Please keep in mind that the maxsize value is a softlimit that can be exceeded in between Tuner runs (remember that these only run every n seconds). When the Tuner thread runs, it will prune the cache down to the maxsize according to the rules of the Policy.

This last point is particularily relevant to those who may be inserting large objects into Whirlycache. For example, if you decide to cache 10Mb PDF files in memory, be sure that your Cache has an appropriately configured max-size and that you run the Tuner frequently enough to account for any activity that could result in something potentially disastrous such as ninety 10Mb files being inserted all of a sudden. If you don't have enough memory allocated to your JVM, you will inevitably get an exception complaining about a lack of memory! The max-size declaration in the whirlycache.xml file tells the configured Policy class to trim the Cache to n elements every time it runs. There is nothing to prevent you from successfully inserting n+1 objects into the cache. It will work, assuming you don't run out of memory.

The Policy defines the set of rules for removing elements from a cache. You can specify a different Policy implementation per named cache in the whirlycache.xml configuration file. Currently, we offer FIFO, LFU and LRU.

Configuration & Installation
To use Whirlycache, simply download the latest distribution and unzip it. Then, copy all of the supplied jar files in your classpath. Finally, you will need to supply a whirlycache.xml file in your classpath as well. You need to properly configure the whirlycache.xml file according to your needs, but we have supplied you with reasonable default values that you can change later if you need to.
Here is a sample whirlycache.xml configuration file.

Whirlycache License

Project Home Page
https://whirlycache.dev.java.net/

Whirlycache Source Code Download
https://whirlycache.dev.java.net/source/browse/whirlycache/

Download Whirlycache
https://whirlycache.dev.java.net/downloads/whirlycache-1.0.1.zip

Jofti is a simple to use, high-performance object indexing and searching solution for Objects in a Caching layer or storage structure that supports the Map interface. The framework supports EHCache, JBossCache and OSCache and provides for transparent addition, removal and updating of objects in its index as well as simple to use query capabilties for searching. Features include type aware searching, configurable object property indexing, indexing/searching by interfaces as well as support for Dynamic Proxies, primitve attributes, Collections and Arrays.

Who needs Jofti?

If you want to be able to quickly search objects in your cache as if it was a datastore, leverage your cache data so you do not have to do expensive repeat fetching from remote systems or add flexible query capabilities to an existing cache. Even if you simply want to be able to find data in a cache or map without knowing the key, then Jofti is for you.

Jofti Supports

Jofti has been designed to allow developers freedom to use the caching solution they prefer as a plug-in or configure its Indexes as listeners for an existing Cache.

Currently supported are:

* IBM ObjectGrid
* Tangosol Coherence
* EHCache
* OSCache
* JBossCache
* Any Map structure

Features

Simple Querying

Jofti currently supports two standard query language formats:

* SQL
* EJB3 QL

The adoption of these standards for the query languages is to provide a low-learning curve for developers and enable easy development of complex queries using well understood idioms.

Ease of Integration

For Caches that support the listener model, Jofti can be added to any application by simply registering an existing Cache with Jofti's IndexManager.

The index is then kept up to date with the Cache no matter where it is used in the application. This means almost zero code change to add querying capabilities to an existing Cache instance.

Memory Management

For applications that have large cache sizes, or operate in a memory-sensitive environment, you can easily specify only a portion of the index data to be kept in memory, with the rest paged to and from disk on-demand.
Flexible licensing

The current release (version 1.1) is available under a dual license of GPL or a Commercial license for those that want to avoid the implications of the GPL license.

Also,

* Multi Cache support
* Transaction support
* Type aware searching
* Configurable property indexing
* Indexing/searching by interfaces
* Support for dynamic proxies
* Support for primitve attributes
* Support for collections and arrays
* String prefix searching
* Simple query language

Jofti Home Page
http://www.jofti.com

Jofti Support Forum
http://jofti.com/forums/

Download Jofti
http://www.jofti.com/download.html

More Open Source Cache Systems

cache4j is a cache for java objects. Simple API and fast implementation.

* in memory caching
* design for multithread environment
* two implementation: synchronized, blocking
* eviction algorithm LFU, LRU, FIFO
* for store object can use strong or soft reference
* available under the BSD license

cache4j Tutorials
http://cache4j.sourceforge.net/tutorial.htm

Cache4j Download
http://sourceforge.net/project/showfiles.php?group_id=160023&package_id=180807&release_id=399978

More Open Source Cache Systems