| Package Name | Comment |
| net.sf.ehcache |
This package contains the public API for using ehcache.
|
| net.sf.ehcache.bootstrap |
This package contains the bootstrap cache loader interface and abstract factory.
|
| net.sf.ehcache.config |
This package contains the cache configuration code.
|
| net.sf.ehcache.constructs.asynchronous |
|
| net.sf.ehcache.constructs.blocking | Test cases for the blocking caches.
|
| net.sf.ehcache.constructs.concurrent |
This package contains the Mutex class and Sync interface taken as is, with fixed for checkstyle and
javadoc errors from version 1.3.4 of Doug Lea's concurrency package.
See http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html
|
| net.sf.ehcache.constructs.web |
Constructs useful for Java EE Web Container environments, specifically the Servlet 2.3 specification.
This package contains a subpackage of caching filters and support objects for it.
|
| net.sf.ehcache.constructs.web.filter |
Caching filters compliant with the filters in the Servlet 2.3 specification.
|
| net.sf.ehcache.constructs.web.servlet |
Servlets to test including and forwarding from a Front Controller
|
| net.sf.ehcache.distribution |
This package is for cache replication.
Overview
Problems with Instance Caches in a Clustered Environment
Many production applications are deployed in clusters. If each application maintains its own cache, then updates
made to one cache will not appear in the others. A workaround for web based applications is to use sticky sessions,
so that a user, having established a session on one server, stays on that server for the rest of the session. A
workaround for transaction processing systems using Hibernate is to do a session.refresh on each persistent object
as part of the save. session.refresh explicitly reloads the object from the database, ignoring any cache values.
Replicated Cache
Another solution is to replicate data between the caches to keep them consistent. This is sometimes called cache
coherency. Applicable operations include:
- put
- update (put which overwrites an existing entry)
- remove
Replicated Cache Terms
Replicated Cache - a cache instance that notifies others when its contents change
Notification - a mechanism to replicate changes
Topology - a layout for how replicated caches connect with and notify each other
Notification Strategies
The best way of notifying of put and update depends on the nature of the cache.
If the Element is not available
anywhere else then the Element itself should form the payload of the notification. An example is a cached web page.
This notification strategy is called copy.
Where the cached data is available in a database, there are two choices. Copy as before, or invalidate the data. By
invalidating the data, the application tied to the other cache instance will be forced to refresh its cache from the
database, preserving cache coherency. Only the Element key needs to be passed over the network.
ehcache supports notification through copy and invalidate, selectable per cache.
Topology Choices
Peer Cache Replicator
Each replicated cache instance notifies every other cache instance when its contents change. This requires n-1
notifications per change, where n is the number of cache instances in the cluster.
Centralised Cache Replicator
Each replicated cache instance notifies a master cache instance when its contents change. The master cache then
notifies the other instances. This requires n-1
notifications per change, where n is the number of cache instances in the cluster.
ehcache uses a peer replication topology. It adds a twist with CachePeerProvider, an interface which supplies a list
of cache instance peers, so as to handle peers entering and leaving the cluster. Some ideas for peer provider
implementations are: configuration time list, multicast discovery, application specific cluster list.
Replication Drawbacks and Solutions in ehcache's implementation
Some potentially significant obstacles have to be overcome if replication is to provide a net benefit.
Chatty Protocol
n-1 notifications need to happen each time a a cache instance change occurs. A very large amount of network traffic
can be generated.
ehcache will buffer changes to lower chattiness.
Redundant Notifications
The cache instance that initiated the change should not receive its own notifications. To do so would add additional
overhead. Also, notifications should not endlessly go back and forth as each cache listener gets changes caused by
a remote replication.
ehcache CachePeerProvider indentifies the local cache instance and excludes it from the notification list. Each Cache
has a GUID. That GUID can be compared with list of cache peers and the local peer excluded.
Infinite notifications are prevented by having each CacheReplicatorListener call putQuiet and removeQuite methods
on their decorated caches, so as not to nofify listeners.
Potential for Inconsisent Data
Timing scenarios, race conditions, delivery and reliability constraints, and concurrent updates to the same cached
data can cause inconsistency (and thus a lack of coherency) across the cache instancies.
Acknowledgement: Much of the material here was drawn from Data Access Patterns, by Clifton Nock.
|
| net.sf.ehcache.distribution.jgroups | |
| net.sf.ehcache.event |
This package contains interfaces and classes for listening to events.
|
| net.sf.ehcache.exceptionhandler |
This package is for exception handling.
Normally, an exception will be thrown. However an exception handler may be registered at configuration
time in ehcache.xml, or set at runtime (a strategy), to handle an exception.
If an exception handler is registered, the default behaviour of throwing the exception will not occur. The handler
method onException will be called. Of course, if the handler decides to throw the exception, it will
propagate up through the call stack. If the handler does not, it won't.
This package defines an ExceptionHandler interface, and also a CacheExceptionHandlerFactory, which is used for
configuration.
|
| net.sf.ehcache.extension |
This package contains interfaces and classes for the cache extension mechanism.
|
| net.sf.ehcache.hibernate |
This package contains interfaces and classes for Hibernate3.1 and higher.
|
| net.sf.ehcache.jcache |
This package contains an implementation of JSR-107: the JCACHE API. The JCache class is an implementation of
JCACHE's cache. It is a decorator to an Ehcache.
|
| net.sf.ehcache.loader |
This package contains a cache loaders and associated factories. The loader concept comes from JSR107.
Ehcache also provides similar functionality in SelfPopulatingCache, in the constructs package.
|
| net.sf.ehcache.management |
This package contains JMX MBeans and implementations for management of ehcache.
This implementation attempts to follow Sun's JMX best practices. See
http://java.sun.com/javase/technologies/core/mntr-mgmt/javamanagement/best-practices.jsp
JMX was packaged with Java in JDK1.5. Keeping all JMX stuff in this package prevents leakage of
JMX concepts
so that JMX does not become a required dependency for ehcache.
The package also enables a separation of concerns so that management does not get mixed with
the implementation.
The client API is exposed through the ManagementService. Use ManagementService.registerMBeans(...)
to register a selection of MBeans to the MBeanServer provided to the method.
|
| net.sf.ehcache.spring | |
| net.sf.ehcache.store |
Store package. This package contains a Store interface and its implementations: a
memory store and a disk store.
Stores are used by the Cache to physically implement logical cache operations.
|
| net.sf.ehcache.util |
Util package. This package contains utilities - common functionality that can be factored out to
utility classes which have public static methods.
|