xdocs/index.xml - commons-jcs - Git at Google

 <?xml version="1.0"?>

 <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>
 			</ul>
 			<p>
 				JCS works on JDK versions 1.3 and up. It only has two
 				dependencies: Commons Logging and Doug Lea's Util
 				Concurrent.
 			</p>
 		</section>

 		<section name="JCS is a Composite Cache">
 			<p>
 				The foundation of JCS is the Composite Cache, which is
 				the
 				<a href="Plugins.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 addtion 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="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 is 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 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.
 			</p>
 		</section>

 	</body>
 </document>
	<?xml version="1.0"?>

	<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>
	</ul>
	<p>
	JCS works on JDK versions 1.3 and up. It only has two
	dependencies: Commons Logging and Doug Lea's Util
	Concurrent.
	</p>
	</section>

	<section name="JCS is a Composite Cache">
	<p>
	The foundation of JCS is the Composite Cache, which is
	the
	<a href="Plugins.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 addtion 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="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 is 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 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.
	</p>
	</section>

	</body>
	</document>