Several issues to be aware of when using Ehcache (GO)

Recently doing a small project requires caching a batch of data and requiring persistence to disk. Using Ehcache is very simple and intuitive, generally only need to configure Ehcache.xml files, and then directly use @cacheable, @Cacheput, @CacheEvict can.

The meaning of the three annotations is also very simple, here is not to say.

The Ehchche.xml configuration is simple and intuitive:

1 <!--Name : Cache names -2     <!--maxelementsinmemory: Maximum number of caches -3     <!--Eternal: Whether the object in the cache is permanent, and if so, the timeout setting is ignored and the object never expires -4     <!--Timetoidleseconds: The allowable idle time (in seconds) of an object before it expires, optional if the Eternal=false object is not permanently valid, the default value is 0, which means that the idle time is infinite -5     <!--Timetoliveseconds: The time-to-live (TTL) of the cached data, which is the maximum time interval value of an element from build to extinction, which can only be valid if the element is not permanently resident, and if the value is 0 means that the element can pause for an infinite amount of time -6     <!--Overflowtodisk: If the disk cache is enabled when there is not enough memory -7     <!--Maxelementsondisk: Set to 0 indicates unlimited maximum number of cache objects on the hard disk -8     <!--diskpersistent: Set to TRUE indicates whether the cache virtual machine Restart period Data disk storage persists after the virtual machine restarts -9     <Cachename= "Appdscache"Ten maxelementsinmemory= "0" One Eternal= "true" A Maxelementsondisk= "10000000" - Overflowtodisk= "true" - diskpersistent= "true" the Memorystoreevictionpolicy= "LRU"> -         <!--<persistence strategy= "localrestartable" synchronouswrites= "false"/> - -     </Cache>

But in the use of the process encountered two small problems, the following simple to make a record.

1. Write a method with a cached annotation in the class, and then invoke the cache function in a normal method, the cache function is no longer valid. as follows:

@EnableCaching class Implements ia{    public  String Funa () {       return  Funb ();          }      @Cacheable    public  String Funb () {        ...    }}

This is in fact related to spring's object injection mechanism, for example, when an object of Class A is obtained externally through a @autowired annotation, it actually gets a spring-wrapped proxy object.

When A.funb () is called, the Funb () method in the Spring proxy object is actually called, which has the cache mechanism built in, and the Funa method in the actual a object is called after the cache is checked.

Similarly, when calling A.funa (), the Funa () method in the Spring proxy object is called first, and after the steps such as check and resource allocation, the Funa () method in the actual a object is called, but when Funb () is called in the actual Class A object, the The cache mechanism is not triggered because the call is not a Springcacheproxy object, but an actual Class A object, so the cache mechanism is not triggered.

If you delve into the principles of spring's completion of injection and AOP programming, you can find that dynamic proxies are a very important technology. Currently, Spring's dynamic agent is mainly implemented by Cglib.

So how is this problem solved? There are two ways of thinking:

(1) split into two classes to achieve. Funa () and Funb () will be written in two classes.

(2) Inject an instance of itself into a class. As follows:

@EnableCaching @service (Value= "a") class Implements ia{    @Resource (name= "a")    private  IA A;       Public String Funa () {       return  A.funb ();          }      @Cacheable    public  String Funb () {        ...    }}

The second method of pro-Test effective ~ ~

In any case, keep in mind that the annotation mechanism may not be valid when the annotation methods in the same class call each other .

2. (When you click the red button in idea to close the program) data persisted to disk cannot be recovered.

The reasons are as follows:Ehcache is similar to other caches and requires flush or shutdown before it is persisted to disk .

The. data file and the index file of the. Index are generated for easy restart recovery.

Ehcache recovery data is based on the. Index index file for data recovery.

When the program starts again, a method of Ehcache will compare the modified time of the. data file with the. index file if it is not compliant to delete the. index file directly.

In general, the shutdown () function is automatically called in the following two cases:

(1) Call System.exit () or the last non-daemon thread to exit.

(2) The virtual machine stops running. For example, execute CTRL + C on the command line, which results in a kill-sigterm pid or kill-15 pid.

When you click on the red button in idea, it is an abnormal shutdown, causing shutdown () to fail, guessing that the method that is similar to kill-9 directly kills the process, rather than kill-15 a more secure shutdown.

It is advisable to call the shutdown () function explicitly before the program closes, but in practice, even if you explicitly call shutdown (), the cache will fail if you click the Red Close button of idea when the program runs halfway.

In my opinion the safest way is to run the program into a jar package, using CTRL + C at the command line to terminate the program, even if the program is not finished, shutdown () will also execute.

Several issues to be aware of when using Ehcache (GO)