| <?xml version="1.0"?> |
| <!-- |
| Licensed to the Apache Software Foundation (ASF) under one or more |
| contributor license agreements. See the NOTICE file distributed with |
| this work for additional information regarding copyright ownership. |
| The ASF licenses this file to you under the Apache License, Version |
| 2.0 (the "License"); you may not use this file except in compliance |
| with the License. You may obtain a copy of the License at |
| http://www.apache.org/licenses/LICENSE-2.0 Unless required by |
| applicable law or agreed to in writing, software distributed under the |
| License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR |
| CONDITIONS OF ANY KIND, either express or implied. See the License for |
| the specific language governing permissions and limitations under the |
| License. |
| --> |
| <document> |
| <properties> |
| <title>Java Caching System</title> |
| <author email="asmuts@apache.org">Aaron Smuts</author> |
| </properties> |
| <body> |
| <section name="Java Caching System"> |
| <p> |
| 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 |
| <a href="UsingJCSBasicWeb.html">most useful</a> |
| for high read, low put applications. Latency times drop sharply and |
| bottlenecks move away from the database in an effectively cached |
| system. |
| <a href="getting_started/intro.html">Learn how to start using JCS.</a> |
| </p> |
| <p> The JCS goes beyond simply caching objects in memory. It provides |
| numerous additional features:</p> |
| <ul> |
| <li>Memory management</li> |
| <li>Disk overflow (and defragmentation)</li> |
| <li>Thread pool controls</li> |
| <li>Element grouping</li> |
| <li>Minimal dependencies</li> |
| <li>Quick nested categorical removal</li> |
| <li>Data expiration (idle time and max life)</li> |
| <li>Extensible framework</li> |
| <li>Fully configurable runtime parameters</li> |
| <li>Region data separation and configuration</li> |
| <li>Fine grained element configuration options</li> |
| <li>Remote synchronization</li> |
| <li>Remote store recovery</li> |
| <li>Non-blocking "zombie" (balking facade) pattern</li> |
| <li>Lateral distribution of elements via HTTP, TCP, or UDP</li> |
| <li>UDP Discovery of other caches</li> |
| <li>Element event handling</li> |
| <li>Remote server chaining (or clustering) and failover</li> |
| <li>Custom event logging hooks</li> |
| <li>Custom event queue injection</li> |
| <li>Custom object serializer injection</li> |
| <li>Key pattern matching retrieval</li> |
| <li>Network efficient multi-key retrieval</li> |
| </ul> |
| <p> JCS 3.x works on JDK versions 1.8 and up. It has no |
| mandatory external dependencies. See the document about |
| <a href="UpgradingFrom2x.html">upgrading</a>.</p> |
| <p> JCS 2.x works on JDK versions 1.6 and up. It only has a |
| dependency on Commons Logging. See the document about |
| <a href="UpgradingFrom13.html">upgrading</a>.</p> |
| </section> |
| <section name="JCS is a Composite Cache"> |
| <p> |
| The foundation of JCS is the Composite Cache, which is the |
| <a href="JCSPlugins.html">pluggable</a> |
| 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. |
| </p> |
| <p> The JCS jar provides production ready implementations of each of |
| the four types of caches. In addition to the core four, JCS also |
| provides additional plugins of each type.</p> |
| <subsection name="LRU Memory Cache"> |
| <p> |
| The LRU Memory Cache is an extremely fast, highly configurable |
| <a href="RegionProperties.html"> memory cache</a> |
| . 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 |
| <a href="JCSvsEHCache.html">competitors</a> |
| . |
| </p> |
| </subsection> |
| <subsection name="Indexed Disk Cache"> |
| <p> |
| The |
| <a href="IndexedDiskAuxCache.html">Indexed Disk Cache</a> |
| is a fast, reliable, and |
| <a href="IndexedDiskCacheProperties.html"> highly configurable</a> |
| 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. |
| </p> |
| </subsection> |
| <subsection name="JDBC Disk Cache"> |
| <p> |
| The |
| <a href="JDBCDiskCache.html">JDBC Disk Cache</a> |
| is a fast, reliable, and |
| <a href="JDBCDiskCacheProperties.html"> highly configurable</a> |
| disk cache. It stores both the keys and elements in a JDBC |
| compatible database. The JDBC disk cache stores elements in |
| a database as BLOBs. Periodically, the table is swept to remove |
| expired elements. Multiple instances can be configured to use a |
| common connection pool. A thread pool can be used to reduce the |
| number of queue worker threads across the system. The |
| <a href="MySQLDiskCacheProperties.html">MySQL version of the JDBC Disk Cache</a> |
| can optimize and repair tables. |
| </p> |
| </subsection> |
| <subsection name="TCP Lateral Cache"> |
| <p> |
| The |
| <a href="LateralTCPAuxCache.html">TCP Lateral Cache</a> |
| provides an easy way to distribute cached data to multiple servers. |
| It comes with a |
| <a href="LateralUDPDiscovery.html">UDP discovery</a> |
| mechanism, so you can add nodes without having to reconfigure the |
| entire farm. The TCP Lateral Cache works by establishing |
| connections with socket server running on other nodes. Each node |
| maintains a connection to every other. Only one server is needed |
| for any number of regions. The client is able to re-establish |
| connections if it looses its connection with another server. The |
| TCP Lateral is |
| <a href="LateralTCPProperties.html"> highly configurable</a> |
| . You can choose to only send data, to not look for data on other |
| servers, to send removes instead of puts, and to filter removes |
| based on hash codes. |
| </p> |
| </subsection> |
| <subsection name="RMI Remote Cache"> |
| <p> |
| JCS also provides an RMI based |
| <a href="RemoteAuxCache.html">Remote Cache Server</a> |
| . Rather than having each node connect to every other node, you can |
| use the remote cache server as the connection point. Each node |
| connects to the remove server, which then broadcasts events to the |
| other nodes. To maintain consistency across a cluster without |
| incurring the overhead of serialization, you can decide to send |
| invalidation messages to the other locals rather than send the |
| object over the wire. The remote cache server holds a serialized |
| version of your objects, so it does not need to be deployed with |
| your class libraries. The remote servers can be chained and a list |
| of failover servers can be configured on the client. |
| </p> |
| </subsection> |
| </section> |
| <section name="What JCS is not"> |
| <p> 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.</p> |
| <p> 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 if the distribution mechanism were transactional. |
| </p> |
| <p> 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.</p> |
| <p> JCS is not a 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 incorporated numerous bug fixes and has added |
| dozens of features, making it the best designed and most feature |
| rich caching solution available.</p> |
| </section> |
| </body> |
| </document> |