Movatterモバイル変換

JCS User's Guide
Core
Auxiliary

Java Caching System

JCS is a distributed caching system written in Java. It is intendedto speed up applications by providing a means to manage cached dataof various dynamic natures. Like any caching system, JCS ismost usefulfor high read, low put applications. Latency times drop sharply andbottlenecks move away from the database in an effectively cachedsystem.Learn how to start using JCS.

The JCS goes beyond simply caching objects in memory. It providesnumerous 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
Custom event logging hooks
Custom event queue injection
Custom object serializer injection
Key pattern matching retrieval
Network efficient multi-key retrieval

JCS 3.x works on JDK versions 1.8 and up. It has no mandatory external dependencies. See the document aboutupgrading.

JCS 2.x works on JDK versions 1.6 and up. It only has adependency on Commons Logging. See the document aboutupgrading.

JCS is a Composite Cache

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

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

LRU Memory Cache

The LRU Memory Cache is an extremely fast, highly configurable memory cache. It uses a Least Recently Used algorithm to manage the number ofitems that can be stored in memory. The LRU Memory Cache uses itsown LRU Map implementation that is significantly faster than boththe commons LRUMap implementation and the LinkedHashMap that isprovided with JDK1.4 up. This makes JCS faster than itscompetitors.

Indexed Disk Cache

TheIndexed Disk Cacheis a fast, reliable, and highly configurableswap for cached data. The indexed disk cache follows the fastestpattern for disk swapping. Cache elements are written to disk via acontinuous queue-based process. The length of the item is stored inthe first few bytes of the entry. The offset is stored in memoryand can be reference via the key. When items are removed from thedisk cache, the location and size are recorded and reused whenpossible. Every aspect of the disk cache is configurable, and athread pool can be used to reduce the number of queue workerthreads across the system.

JDBC Disk Cache

TheJDBC Disk Cacheis a fast, reliable, and highly configurabledisk cache. It stores both the keys and elements in a JDBCcompatible database. The JDBC disk cache stores elements ina database as BLOBs. Periodically, the table is swept to removeexpired elements. Multiple instances can be configured to use acommon connection pool. A thread pool can be used to reduce thenumber of queue worker threads across the system. TheMySQL version of the JDBC Disk Cachecan optimize and repair tables.

TCP Lateral Cache

TheTCP Lateral Cacheprovides an easy way to distribute cached data to multiple servers.It comes with aUDP discoverymechanism, so you can add nodes without having to reconfigure theentire farm. The TCP Lateral Cache works by establishingconnections with socket server running on other nodes. Each nodemaintains a connection to every other. Only one server is neededfor any number of regions. The client is able to re-establishconnections if it looses its connection with another server. TheTCP Lateral is highly configurable. You can choose to only send data, to not look for data on otherservers, to send removes instead of puts, and to filter removesbased on hash codes.

RMI Remote Cache

JCS also provides an RMI basedRemote Cache Server. Rather than having each node connect to every other node, you canuse the remote cache server as the connection point. Each nodeconnects to the remove server, which then broadcasts events to theother nodes. To maintain consistency across a cluster withoutincurring the overhead of serialization, you can decide to sendinvalidation messages to the other locals rather than send theobject over the wire. The remote cache server holds a serializedversion of your objects, so it does not need to be deployed withyour class libraries. The remote servers can be chained and a listof failover servers can be configured on the client.

What JCS is not

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

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

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

JCS is not a fork, an offshoot, a branch, or any other derivationof JCS. Nor is JCS named after another library. JCS is a matureproject that has been under development and in use since 2001. Overthe years JCS has incorporated numerous bug fixes and has addeddozens of features, making it the best designed and most featurerich caching solution available.