The default Cacheprovider--ehcacheprovider principle in Hibernate

Ehcache is now the most popular Java open-source caching framework, simple to configure, well-structured, powerful, and initially known to start with Hibernate's cache. On-line Chinese Ehcache materials to simple introduction and configuration methods, if you have this problem, please Google, for the API, the official website is very clear, please refer to the official site, but rarely see the description of features and analysis of the implementation principle, so in this article, I will introduce and analyze the characteristics of Ehcache, plus some of my own understanding and thinking, I hope the cache interested in friends to gain.

first, features at a glance , from the official website, simple translation:

1. Fast and light weight
Over the past few years, many tests have shown that Ehcache is one of the fastest Java caches.
Ehcache's threading mechanism is designed for large, high-concurrency systems.
A large number of performance test cases ensure that ehcache performance is consistent across different versions.
Many users do not know that they are using ehcache because they do not need any special configuration.
The API is easy to use, which makes it easy to deploy on-line and run.
Very small jar package, Ehcache 2.2.3 668kb.
Minimal dependency: The only dependency is slf4j.

2. Flexibility
Caching in memory and disk storage can be scaled up to several g,ehcache for big data storage optimizations.
In case of large memory, all processes can support hundreds of g of throughput.
Optimized for high concurrency and large multi-CPU servers.
Thread safety and performance are always conflicting, and Ehcache's threading mechanism design uses Doug Lea's idea to achieve higher performance.
Multiple cache managers are supported on a single virtual machine.
With the terracotta server matrix, you can scale to hundreds of nodes.

3. Flexibility
Ehcache 1.2 has an Object API interface and a serializable API interface.
An object that cannot be serialized can use all features except the disk storage Ehcache.
In addition to the element's return method, the API is unified. Only these two methods are inconsistent: Getobjectvalue and Getkeyvalue. This makes the process of caching objects, serializing objects, and acquiring new features simple.
Cache-based and element-based expiration policies are supported, and the time to live for each cache can be set and controlled.
The LRU, LFU and FIFO cache culling algorithms are provided, and the Ehcache 1.2 introduces a least-used and first-in-a-go cache culling algorithm, which constitutes a complete cache-culling algorithm.
Providing memory and disk storage, Ehcache provides high-performance memory and disk storage like most cache solutions.
Dynamic, runtime cache configuration, the maximum number of live, idle, memory, and disk storage caches can be modified at run time.

4. Standard Support
Ehcache provides the most complete implementation of the JSR107 Jcache API. Since Jcache was released, Ehcache implementations (such as Net.sf.jsr107cache) have been released.
Implementing the Jcache API facilitates portability of other caching solutions in the future.
Ehcache's maintainer, Greg Luck, is a member of JSR107 's expert committee.

5. Scalability
The listener can be plug-in. The Ehcache 1.2 provides Cachemanagereventlistener and Cacheeventlistener interfaces, which can be plug-in and configured in Ehcache.xml.
Node discovery, both the redundancy and the listener can be plug-in.
Distributed cache, introduced from Ehcache 1.2, contains a number of tradeoff options. Ehcache's team believes that nothing is a universal configuration.
The implementation can use the built-in mechanism or implement it entirely on its own, as there is a complete plug-in development guide.
The scalability of the cache can be plug-in. Create your own cache extension, which can hold a cached reference and bind to the cache life cycle.
The cache loader can be plug-in. To create your own cache loader, you can use some asynchronous methods to load data into the cache.
The cache exception handler can be plug-in. Creates an exception handler that can perform certain actions when an exception occurs.

6, the application of persistent
After a VM restarts, storage that is persisted to disk can recover data.
Ehcache is the first open-source Java caching framework that introduces cache data persistence storage. The cached data can be re-acquired from disk after the machine restarts.
Swipe the cache to disk as needed. The operation of swiping a cache entry to disk can be performed through the Cache.flush () method, which greatly facilitates the use of ehcache.

7. Listener
Cache Manager Listener. Allows registering a listener that implements the Cachemanagereventlistener interface:
Notifycacheadded ()
Notifycacheremoved ()
Caches event listeners. Allows registering a listener that implements the Cacheeventlistener interface, which provides many of the processing mechanisms that occur after a cache event occurs:
Notifyelementremoved/put/updated/expired

8. Open JMX
The JMX functionality of Ehcache is enabled by default, and you can monitor and manage the following mbean:
CacheManager, Cache, Cacheconfiguration, Cachestatistics

9. Distributed Cache
Starting with Ehcache 1.2, it supports high-performance distributed caching with flexibility and scalability.
Options for distributed caching include:
Cache cluster via terracotta: Sets and uses the Ehcache cache of the terracotta mode. Cache discovery is done automatically, and there are many options for debugging cache behavior and performance.
Use RMI, jgroups, or JMS to cache data redundantly: Nodes can be configured manually by multicast or by a discovery person. Status updates can be done asynchronously or synchronously through RMI connections.
Custom: A comprehensive plug-in mechanism that supports the ability to discover and replicate.
The available cache replication options. Support for asynchronous or synchronous cache replication over RMI, jgroups, or JMS.
Reliable distribution: Use TCP's built-in distribution mechanism.
Node discovery: Nodes can be configured manually or using multicast Autodiscover, and nodes can be added and removed automatically. In the case of multicast blocking, manual configuration can be very well controlled.
The distributed cache can join or leave the cluster at any time. The cache can be configured to execute the bootstrap programmer at initialization time.
Bootstrapcacheloaderfactory Abstract Factory, implements the Bootstrapcacheloader interface (RMI implementation).
Cache service side. Ehcache provides a cache server, a war package, to support the vast majority of web containers or standalone servers.
The cache server has two sets of APIs: resource-oriented restful, and soap. The client does not implement language restrictions.
RESTful cache server: the implementation of ehcached strictly follows the restful resource-oriented architectural style.
SOAP cache server: The Ehcache RESTFul Web Services API exposes a singleton CacheManager, which can be configured in Ehcache.xml or IOC containers.
The standard service side contains an embedded GlassFish Web container. It was made into a war package and can be deployed arbitrarily into a web container that supports servlet 2.5. Glassfish V2/3, Tomcat 6 and Jetty 6 have all been tested.

10. Search
Standard distributed search uses the way the streaming query interface is used, see the documentation.

11. Java EE and application cache
Provides a high-quality implementation for normal cache scenarios and patterns.
Blocking caching: Its mechanism avoids the problem of concurrent operation of the replication process.
Selfpopulatingcache is especially useful when caching some expensive operations, which is a cache for read-optimized caching. It does not require the caller to know how the cache element is returned, and it also supports refreshing the cache entry without blocking the read.
Cachingfilter: An abstract, extensible cache filter.
Simplepagecachingfilter: Used to cache pages based on the request URI and query string. It can choose to use or not use gzip compression to send pages to the browser based on the value of the HTTP request header. You can use it to cache the entire Servlet page, whether you're using JSP, velocity, or other page rendering techniques.
Simplepagefragmentcachingfilter: Cache page fragments, based on request URI and query String. Use the jsp:include tag included in the JSP.
Already tested with Orion and Tomcat, compatible with servlet 2.3, servlet 2.4 specification.
cacheable command: This is an old command-line pattern that supports asynchronous behavior, fault tolerance.
Compatible with hibernate, compatible with Google App Engine.
JTA-based transaction support, support for transactional resource management, two-phase commit and rollback, and local transactions.

12. Open Source Agreement
Apache 2.0 License

Second, ehcache the list of loading modules , they are independent libraries, each to add new features for Ehcache, can be downloaded here:

EHCACHE-CORE:API, standard cache engine, RMI replication, and hibernate support Ehcache: Distributed Ehcache, including Ehcache's core and terracotta's library Ehcache-monitor: enterprise-level monitoring and management Ehcache-web: Implementation of filters ehcache-jcache:jsr107 Jcache for Java Servlet container that provides caching, gzip compression support Ehcache-jgroupsreplication: Replication ehcache-jmsreplication using Jgroup: Replication EHCACHE-OPENJPA:OPENJPA plug-in with JMS RESTful cache server Ehcache-unlockedreadsview deployed in Ehcache-server:war or deployed separately: Allows terracotta cache for lock-free read Ehcache-debugger: Logging RMI distributed call Event Ehcache for Ruby:jruby and rails support

Overview of Ehcache structure design:

Third, the core definition :

Cache Manager: Caching manager, previously only allowed Singleton, but now also can be more instances of

Cache: Caches can be placed in the buffer manager to hold the essence of the data, all caches have implemented the Ehcache interface

Element: The constituent unit of a single cached data

System of Record (SOR): A component that can fetch real data, a real business logic, an external interface call, a database that holds real data, and so on, which is read from the Sor or written to the Sor.

Code example: Java code    cachemanager manager = cachemanager.newinstance ("src/config/ Ehcache.xml ");   Manager.addcache (" Testcache ");   cache test =  Singletonmanager.getcache ("Testcache");   Test.put (new element ("Key1",  "value1");    Manager.shutdown ();  

Of course, this kind of DSL-like configuration is also supported, and the configuration can be dynamically modified at runtime: Java code    cache testcache = new cache (      new cacheconfiguration ("Testcache",  maxelements)         .memorystoreevictionpolicy (MEMORYSTOREEVICTIONPOLICY.LFU)        . Overflowtodisk (True)        .eternal (false)        . Timetoliveseconds        .timetoidleseconds (+)         .diskpersistent (False)        .diskexpirythreadintervalseconds (0));   

Example of a transaction: Java code Ehcache cache = Cachemanager.getehcache ("Xacache");   Transactionmanager.begin ();       try {Element e = cache.get (key);       Object result = Complexservice.dostuff (Element.getvalue ());       Cache.put (New Element (key, result));       Complexservice.domorestuff (result);   Transactionmanager.commit ();   } catch (Exception e) {transactionmanager.rollback (); }

Iv. Conformance Model :

When it comes to consistency, what is the consistency of the database? You might want to review some of the database's isolation levels first:

Uncommitted read (READ UNCOMMITTED): No locks are checked or used when reading data. Therefore, data that is not committed may be read in this isolation level. Dirty reads, non-repeatable reads, Phantom reads can occur.
Read Committed: Read committed data only and wait for other transactions to release exclusive locks. Shared locks for read data are released as soon as the read operation is complete. Read Committed is the default isolation level for the database. There will be non-repeatable read, Phantom read.
REPEATABLE READ (REPEATABLE READ): Reads data as read-committed, but retains shared locks until the end of the transaction. Phantom reads will appear.
Serializable (Serializable): works like repeatable reads. But not only does it lock the affected data, it also locks the range, which prevents new data from being inserted into the query.

Based on the above, consider the following consistency model:

1. Strong consistency model: After a successful update of a data in the system (the transaction returns successfully), any subsequent read operations to that data are updated values. This is the consistency model provided by the traditional relational database, and is one of the reasons why the relational database is loved by people. Performance consumption is usually the largest under a strong consistency model.

2, weak consistency model: After the data in the system is updated, the subsequent read operation of the data is not necessarily the updated value, in this case there is usually an "inconsistency window" exists: that is, after the data update is completed in this time window, subsequent read operations can be updated value.

3, the final consistency model: one of the weak consistency, that is, when a data is updated, if the data is not updated again later, then all the read operations will return the updated value.

The final consistency model contains the following necessary properties, which are better understood:

Read-write consistent: A thread A, after updating a piece of data, subsequent access to all can obtain updated data. Session Consistency: It is essentially the same as the one above, a user changes the data, as long as the session is still there, all the data that he obtains must be the changed data. Monotonic Read consistency: If a process can see the current value, subsequent accesses cannot return the previous value. Monotone write Consistency: The write behavior within the same process must be guaranteed, otherwise, the finished result is not expected.

4, Bulk load: This model is based on the bulk loading of data into the cache inside the scene and optimized, there is no lock and general elimination algorithm to reduce the performance of things, it is similar to the final consistency model, but there are batch, high sketch and weak consistency guarantee mechanism.

These APIs can also affect the results of consistency:

1, explicit Lock (Explicit Locking): If we are configured for strong consistency, then naturally all cache operations have transactional nature. And if we are configured for eventual consistency, then the explicit lock API is used externally, and the effect of the transaction can be achieved. Of course, such locks can be finer grained, but there may still be competition and thread blocking.

2. Lock-Free readable view (Unlockedreadsview): A decorator that allows dirty reads, it can only be used in a strong consistency configuration, and it improves performance by requesting a special write lock that is better than a full strong consistency configuration.

For example, the XML is configured as a strong consistency model: XML code <cache name= "Mycache" maxelementsinmemory= "eternal=", "false" OVERFL Owtodisk= "false" <terracotta clustered= "true" consistency= "strong"/> </cache>

But use the Unlockedreadsview:java code cache cache = Cachemanager.getehcache ("Mycache"); Unlockedreadsview Unlockedreadsview = new Unlockedreadsview (cache, "Myunlockedcache");

3, Atomic method (Atomic Methods): Method execution is atomized, that is, the CAS operation (Compare and Swap). CAs eventually achieved strong consistency, but the difference was that it was implemented using optimistic locks rather than pessimistic locks. Under the optimistic locking mechanism, the updated operation may not be successful because there may be other threads in the process that make changes to the same data, and then the update operation needs to be re-executed after the failure. The modern CPU supports CAS primitives.   Java code cache.putifabsent (element Element);   Cache.replace (element Oldone, element Newone); Cache.remove (Element);

v. Cache topology Type :

1. Independent cache (Standalone Ehcache)