As of version 2.0, the core of JCS (the LRU memory cache, the indexed disk cache, the TCP lateral, and the RMI remote server) only requires commons-logging.
As of version 1.2.7.0, the core of JCS (the LRU memory cache, the indexed disk cache, the TCP lateral, and the RMI remote server) requires only two other jars.
commons-logging
Versions 1.2.6.9 and below also require the following two additional jars:
commons-collections
commons-lang
All of the other dependencies listed on the project info page are for optional plugins.
By default JCS looks for a cache.ccf file in the classpath. You must have a configuration file on the classpath to use JCS. The documentation describes how to configure the cache.
You don't have to put the cache.ccf file in the classpath; instead you can do the following:
CompositeCacheManager ccm =
CompositeCacheManager.getUnconfiguredInstance();
Properties props = new Properties();
props.load(/* load properties from some location
defined by your app */);
ccm.configure(props);
Yes. JCS will look for a system property for any name inside the delimiters ${}. Also, JCS will check to see if any property key in the cache.ccf is defined in the system properties. If so, the system value will be used.
Yes. JCS is almost twice as fast as EHCache. JCS 1.2.7.0, using the default LRU Memory Cache, has proven to be nearly twice as fast as EHCache 1.2-beta4 at gets and puts. The EHCache benchmark data is unsubstantiated and very old. As such the EHCache site benchmark data is completely inaccurate. Read More
You can download the admin jsp here .
You can view the source
here
or get the source code from subversion with svn co
http://svn.apache.org/repos/asf/commons/proper/jcs/trunk.
The tagged releases are available with svn co. ex.
http://svn.apache.org/repos/asf/commons/proper/jcs/tags/jcs_1_2_7_0
You first need to install Maven 2 The download is available at http://maven.apache.org/download.html. After installing run "mvn test" which compiles and tests the entire package. To build a jar run "mvn install".
Every element put into the cache has its own set of attributes. By default elements are given a copy of the default element attributes associated with a region. You can also specify the attributes to use for an element when you put it in the cache. See Element Attributes for more information on the attributes that are available.
Element event handlers must be added to the element attributes. See Element Event Handling for more information on how to handle element events.
Yes, but it is somewhat expensive, since some of the auxiliaries will have to iterate over their keysets. Although all the auxiliaries honor this, it is not part of the auxiliary API. There is no method along the lines of "removeStartingWith", but all the remove methods can do it.
By default, the hierarchical key delimiter used in JCS is a colon. You cannot add a String key that ends with a colon. If you call remove with a String key that ends in a colon, everything that has a key that starts with the argument will be removed.
If your keys are in this format
TYPE:SOURCE:OBJECT
And you put n objects int he cache with keys like this
"ABC:123:0" to "ABC:123:n"
then you could remove all the obejcts by calling
jcs.remove( "ABC:123:" );
The indexed disk cache uses an event queue for each region. By default these queues are worked by their own dedicated threads. Hence, you will have one thread per disk cache region. Although the queues kill off idle threads, you may want to limit the overall number of threads used by the queues. You can do this by telling the disk cache to use a thread pool. The configuration is described on the disk cache configuration page .
No. The remote server never deserializes your classes.