ehcache实例

ehcache.xml说明：

01. <? xml version="1.0" encoding="UTF-8" ?>   
02.  
03. <!--  CacheManager Configuration ========================== An ehcache.xml   
04.    corresponds to a single CacheManager. See instructions below or the ehcache   
05.    schema (ehcache.xsd) on how to configure. System property tokens can be specified   
06.    in this file which are replaced when the configuration is loaded. For example   
07.    multicastGroupPort=${multicastGroupPort} can be replaced with the System   
08.    property either from an environment variable or a system property specified   
09.    with a command line switch such as -DmulticastGroupPort=4446. The attributes   
10.    of <ehcache> are: * name - an optional name for the CacheManager. The name   
11.    is optional and primarily used for documentation or to distinguish Terracotta   
12.    clustered cache state. With Terracotta clustered caches, a combination of   
13.    CacheManager name and cache name uniquely identify a particular cache store   
14.    in the Terracotta clustered memory. * updateCheck - an optional boolean flag   
15.    specifying whether this CacheManager should check for new versions of Ehcache   
16.    over the Internet. If not specified, updateCheck="true". * monitoring - an   
17.    optional setting that determines whether the CacheManager should automatically   
18.    register the SampledCacheMBean with the system MBean server. Currently, this   
19.    monitoring is only useful when using Terracotta clustering and using the   
20.    Terracotta Developer Console. With the "autodetect" value, the presence of   
21.    Terracotta clustering will be detected and monitoring, via the Developer   
22.    Console, will be enabled. Other allowed values are "on" and "off". The default   
23.    is "autodetect". This setting does not perform any function when used with   
24.    JMX monitors. * dynamicConfig - an optional setting that can be used to disable   
25.    dynamic configuration of caches associated with this CacheManager. By default   
26.    this is set to true - i.e. dynamic configuration is enabled. Dynamically   
27.    configurable caches can have their TTI, TTL and maximum disk and in-memory   
28.    capacity changed at runtime through the cache's configuration object.  -->   
29. < ehcache  xmlns:xsi ="http://www.w3.org/2001/XMLSchema-instance"   
30.    xsi:noNamespaceSchemaLocation ="ehcache.xsd"  updateCheck ="true"   
31.    monitoring ="autodetect"  dynamicConfig ="true" >   
32.  
33.     <!--  DiskStore configuration ======================= The diskStore element   
34.        is optional. To turn off disk store path creation, comment out the diskStore   
35.        element below. Configure it if you have overflowToDisk or diskPersistent   
36.        enabled for any cache. If it is not configured, and a cache is created which   
37.        requires a disk store, a warning will be issued and java.io.tmpdir will automatically   
38.        be used. diskStore has only one attribute - "path". It is the path to the   
39.        directory where .data and .index files will be created. If the path is one   
40.        of the following Java System Property it is replaced by its value in the   
41.        running VM. For backward compatibility these should be specified without   
42.        being enclosed in the ${token} replacement syntax. The following properties   
43.        are translated: * user.home - User's home directory * user.dir - User's current   
44.        working directory * java.io.tmpdir - Default temp file path * ehcache.disk.store.dir   
45.        - A system property you would normally specify on the command line e.g. java   
46.        -Dehcache.disk.store.dir=/u01/myapp/diskdir  Subdirectories can be specified   
47.        below the property e.g. java.io.tmpdir/one  -->   
48.     < diskStore  path ="java.io.tmpdir"   />   
49.  
50.  
51.     <!--  TransactionManagerLookup configuration ======================================   
52.        This class is used by ehcache to lookup the JTA TransactionManager use in   
53.        the application using an XA enabled ehcache. If no class is specified then   
54.        DefaultTransactionManagerLookup will find the TransactionManager in the following   
55.        order *GenericJNDI (i.e. jboss, where the property jndiName controls the   
56.        name of the TransactionManager object to look up) *Websphere *Bitronix *Atomikos   
57.        You can provide you own lookup class that implements the net.sf.ehcache.transaction.manager.TransactionManagerLookup   
58.        interface.  -->   
59.  
60.     < transactionManagerLookup  
61.        class ="net.sf.ehcache.transaction.manager.DefaultTransactionManagerLookup"   
62.        properties =""  propertySeparator =":"   />   
63.  
64.     <!--  CacheManagerEventListener ========================= Specifies a CacheManagerEventListenerFactory   
65.        which is notified when Caches are added or removed from the CacheManager.   
66.        The attributes of CacheManagerEventListenerFactory are: * class - a fully   
67.        qualified factory class name * properties - comma separated properties having   
68.        meaning only to the factory. Sets the fully qualified class name to be registered   
69.        as the CacheManager event listener. The events include: * adding a Cache   
70.        * removing a Cache Callbacks to listener methods are synchronous and unsynchronized.   
71.        It is the responsibility of the implementer to safely handle the potential   
72.        performance and thread safety issues depending on what their listener is   
73.        doing. If no class is specified, no listener is created. There is no default.  -->   
74.  
75.     < cacheManagerEventListenerFactory  
76.        class =""  properties =""   />   
77.  
78.     <!--  TerracottaConfig ======================== (Enable for Terracotta clustered   
79.        operation) Note: You need to install and run one or more Terracotta servers   
80.        to use Terracotta clustering. See http://www.terracotta.org/web/display/orgsite/Download.   
81.        Specifies a TerracottaConfig which will be used to configure the Terracotta   
82.        runtime for this CacheManager. Configuration can be specified in two main   
83.        ways: by reference to a source of configuration or by use of an embedded   
84.        Terracotta configuration file. To specify a reference to a source (or sources)   
85.        of configuration, use the url attribute. The url attribute must contain a   
86.        comma-separated list of: * path to Terracotta configuration file (usually   
87.        named tc-config.xml) * URL to Terracotta configuration file * <server host>:<port>   
88.        of running Terracotta Server instance Simplest example for pointing to a   
89.        Terracotta server on this machine: <terracottaConfig url="localhost:9510"/>   
90.        Example using a path to Terracotta configuration file: <terracottaConfig   
91.        url="/app/config/tc-config.xml"/> Example using a URL to a Terracotta configuration   
92.        file: <terracottaConfig url="http://internal/ehcache/app/tc-config.xml"/>   
93.        Example using multiple Terracotta server instance URLs (for fault tolerance):   
94.        <terracottaConfig url="host1:9510,host2:9510,host3:9510"/> To embed a Terracotta   
95.        configuration file within the ehcache configuration, simply place a normal   
96.        Terracotta XML config within the <terracottaConfig> element. Example: <terracottaConfig>   
97.        <tc-config> <servers> <server host="server1" name="s1"/> <server host="server2"   
98.        name="s2"/> </servers> <clients> <logs>app/logs-%i</logs> </clients> </tc-config>   
99.        </terracottaConfig> For more information on the Terracotta configuration,   
100.        see the Terracotta documentation.  -->   
101.  
102.  
103.     <!--  Cache configuration =================== The following attributes are   
104.        required. name: Sets the name of the cache. This is used to identify the   
105.        cache. It must be unique. maxElementsInMemory: Sets the maximum number of   
106.        objects that will be created in memory maxElementsOnDisk: Sets the maximum   
107.        number of objects that will be maintained in the DiskStore The default value   
108.        is zero, meaning unlimited. eternal: Sets whether elements are eternal. If   
109.        eternal, timeouts are ignored and the element is never expired. overflowToDisk:   
110.        Sets whether elements can overflow to disk when the memory store has reached   
111.        the maxInMemory limit. The following attributes and elements are optional.   
112.        overflowToOffHeap: (boolean) This feature is available only in enterprise   
113.        versions of Ehcache. When set to true, enables the cache to utilize "off-heap"   
114.        memory storage to improve performance. Off-heap memory is not subject to   
115.        Java GC cycles and has a size limit set by the Java property MaxDirectMemorySize.   
116.        The default value is false. maxMemoryOffHeap: (string) This feature is available   
117.        only in enterprise versions of Ehcache. Sets the amount of off-heap memory   
118.        available to the cache. This attribute's values are given as <number>k|K|m|M|g|G|t|T   
119.        for kilobytes (k|K), megabytes (m|M), gigabytes (g|G), or terrabytes (t|T).   
120.        For example, maxMemoryOffHeap="2g" allots 2 gigabytes to off-heap memory.   
121.        In effect only if overflowToOffHeap is true. timeToIdleSeconds: Sets the   
122.        time to idle for an element before it expires. i.e. The maximum amount of   
123.        time between accesses before an element expires Is only used if the element   
124.        is not eternal. Optional attribute. A value of 0 means that an Element can   
125.        idle for infinity. The default value is 0. timeToLiveSeconds: Sets the time   
126.        to live for an element before it expires. i.e. The maximum time between creation   
127.        time and when an element expires. Is only used if the element is not eternal.   
128.        Optional attribute. A value of 0 means that and Element can live for infinity.   
129.        The default value is 0. diskPersistent: Whether the disk store persists between   
130.        restarts of the Virtual Machine. The default value is false. diskExpiryThreadIntervalSeconds:   
131.        The number of seconds between runs of the disk expiry thread. The default   
132.        value is 120 seconds. diskSpoolBufferSizeMB: This is the size to allocate   
133.        the DiskStore for a spool buffer. Writes are made to this area and then asynchronously   
134.        written to disk. The default size is 30MB. Each spool buffer is used only   
135.        by its cache. If you get OutOfMemory errors consider lowering this value.   
136.        To improve DiskStore performance consider increasing it. Trace level logging   
137.        in the DiskStore will show if put back ups are occurring. clearOnFlush: whether   
138.        the MemoryStore should be cleared when flush() is called on the cache. By   
139.        default, this is true i.e. the MemoryStore is cleared. memoryStoreEvictionPolicy:   
140.        Policy would be enforced upon reaching the maxElementsInMemory limit. Default   
141.        policy is Least Recently Used (specified as LRU). Other policies available   
142.        - First In First Out (specified as FIFO) and Less Frequently Used (specified   
143.        as LFU) Cache elements can also contain sub elements which take the same   
144.        format of a factory class and properties. Defined sub-elements are: * cacheEventListenerFactory   
145.        - Enables registration of listeners for cache events, such as put, remove,   
146.        update, and expire. * bootstrapCacheLoaderFactory - Specifies a BootstrapCacheLoader,   
147.        which is called by a cache on initialisation to prepopulate itself. * cacheExtensionFactory   
148.        - Specifies a CacheExtension, a generic mechansim to tie a class which holds   
149.        a reference to a cache to the cache lifecycle. * cacheExceptionHandlerFactory   
150.        - Specifies a CacheExceptionHandler, which is called when cache exceptions   
151.        occur. * cacheLoaderFactory - Specifies a CacheLoader, which can be used   
152.        both asynchronously and synchronously to load objects into a cache. More   
153.        than one cacheLoaderFactory element can be added, in which case the loaders   
154.        form a chain which are executed in order. If a loader returns null, the next   
155.        in chain is called. Cache Event Listeners All cacheEventListenerFactory elements   
156.        can take an optional property listenFor that describes which events will   
157.        be delivered in a clustered environment. The listenFor attribute has the   
158.        following allowed values: * all - the default is to deliver all local and   
159.        remote events * local - deliver only events originating in the current node   
160.        * remote - deliver only events originating in other nodes Example of setting   
161.        up a logging listener for local cache events: <cacheEventListenerFactory   
162.        class="my.company.log.CacheLogger" listenFor="local" /> Cache Exception Handling   
163.        ++++++++++++++++++++++++ By default, most cache operations will propagate   
164.        a runtime CacheException on failure. An interceptor, using a dynamic proxy,   
165.        may be configured so that a CacheExceptionHandler can be configured to intercept   
166.        Exceptions. Errors are not intercepted. It is configured as per the following   
167.        example: <cacheExceptionHandlerFactory class="com.example.ExampleExceptionHandlerFactory"   
168.        properties="logLevel=FINE"/> Caches with ExceptionHandling configured are   
169.        not of type Cache, but are of type Ehcache only, and are not available using   
170.        CacheManager.getCache(), but using CacheManager.getEhcache(). Cache Loader   
171.        ++++++++++++ A default CacheLoader may be set which loads objects into the   
172.        cache through asynchronous and synchronous methods on Cache. This is different   
173.        to the bootstrap cache loader, which is used only in distributed caching.   
174.        It is configured as per the following example: <cacheLoaderFactory class="com.example.ExampleCacheLoaderFactory"   
175.        properties="type=int,startCounter=10"/> XA Cache ++++++++ To enable an ehcache   
176.        as a participant in the JTA Transaction, just have the following attribute   
177.        transactionalMode="xa", otherwise the default is transactionalMode="off"   
178.        Cache Writer ++++++++++++ A CacheWriter maybe be set to write to an underlying   
179.        resource. Only one CacheWriter can be been to a cache. It is configured as   
180.        per the following example for write-through: <cacheWriter writeMode="write-through"   
181.        notifyListenersOnException="true"> <cacheWriterFactory class="net.sf.ehcache.writer.TestCacheWriterFactory"   
182.        properties="type=int,startCounter=10"/> </cacheWriter> And it is configured   
183.        as per the following example for write-behind: <cacheWriter writeMode="write-behind"   
184.        minWriteDelay="1" maxWriteDelay="5" rateLimitPerSecond="5" writeCoalescing="true"   
185.        writeBatching="true" writeBatchSize="1" retryAttempts="2" retryAttemptDelaySeconds="1">   
186.        <cacheWriterFactory class="net.sf.ehcache.writer.TestCacheWriterFactory"   
187.        properties="type=int,startCounter=10"/> </cacheWriter> The cacheWriter element   
188.        has the following attributes: * writeMode: the write mode, write-through   
189.        or write-behind These attributes only apply to write-through mode: * notifyListenersOnException:   
190.        Sets whether to notify listeners when an exception occurs on a writer operation.   
191.        These attributes only apply to write-behind mode: * minWriteDelay: Set the   
192.        minimum number of seconds to wait before writing behind. If set to a value   
193.        greater than 0, it permits operations to build up in the queue. This is different   
194.        from the maximum write delay in that by waiting a minimum amount of time,   
195.        work is always being built up. If the minimum write delay is set to zero   
196.        and the CacheWriter performs its work very quickly, the overhead of processing   
197.        the write behind queue items becomes very noticeable in a cluster since all   
198.        the operations might be done for individual items instead of for a collection   
199.        of them. * maxWriteDelay: Set the maximum number of seconds to wait before   
200.        writing behind. If set to a value greater than 0, it permits operations to   
201.        build up in the queue to enable effective coalescing and batching optimisations.   
202.        * writeBatching: Sets whether to batch write operations. If set to true,   
203.        writeAll and deleteAll will be called on the CacheWriter rather than write   
204.        and delete being called for each key. Resources such as databases can perform   
205.        more efficiently if updates are batched, thus reducing load. * writeBatchSize:   
206.        Sets the number of operations to include in each batch when writeBatching   
207.        is enabled. If there are less entries in the write-behind queue than the   
208.        batch size, the queue length size is used. * rateLimitPerSecond: Sets the   
209.        maximum number of write operations to allow per second when writeBatching   
210.        is enabled. * writeCoalescing: Sets whether to use write coalescing. If set   
211.        to true and multiple operations on the same key are present in the write-behind   
212.        queue, only the latest write is done, as the others are redundant. * retryAttempts:   
213.        Sets the number of times the operation is retried in the CacheWriter, this   
214.        happens after the original operation. * retryAttemptDelaySeconds: Sets the   
215.        number of seconds to wait before retrying an failed operation. Cache Extension   
216.        +++++++++++++++ CacheExtensions are a general purpose mechanism to allow   
217.        generic extensions to a Cache. CacheExtensions are tied into the Cache lifecycle.   
218.        CacheExtensions are created using the CacheExtensionFactory which has a <code>createCacheCacheExtension()</code>   
219.        method which takes as a parameter a Cache and properties. It can thus call   
220.        back into any public method on Cache, including, of course, the load methods.   
221.        Extensions are added as per the following example: <cacheExtensionFactory   
222.        class="com.example.FileWatchingCacheRefresherExtensionFactory" properties="refreshIntervalMillis=18000,   
223.        loaderTimeout=3000, flushPeriod=whatever, someOtherProperty=someValue "/>   
224.        Terracotta Clustering +++++++++++++++++++++ Cache elements can also contain   
225.        information about whether the cache can be clustered with Terracotta. The   
226.        <terracotta> sub-element has the following attributes: * clustered=true|false   
227.        - indicates whether this cache should be clustered with Terracotta. By default,   
228.        if the <terracotta> element is included, clustered=true. * valueMode=serialization|identity   
229.        - indicates whether this cache should be clustered with serialized copies   
230.        of the values or using Terracotta identity mode. By default, values will   
231.        be cached in serialization mode which is similar to other replicated Ehcache   
232.        modes. The identity mode is only available in certain Terracotta deployment   
233.        scenarios and will maintain actual object identity of the keys and values   
234.        across the cluster. In this case, all users of a value retrieved from the   
235.        cache are using the same clustered value and must provide appropriate locking   
236.        for any changes made to the value (or objects referred to by the value).   
237.        * synchronousWrites=true|false - When set to true, clustered caches use Terracotta   
238.        SYNCHRONOUS WRITE locks. Asynchronous writes (synchronousWrites="false")   
239.        maximize performance by allowing clients to proceed without waiting for a   
240.        "transaction received" acknowledgement from the server. Synchronous writes   
241.        (synchronousWrites="true") maximize data safety by requiring that a client   
242.        receive server acknowledgement of a transaction before that client can proceed.   
243.        If coherence mode is disabled using configuration (coherent="false") or through   
244.        the coherence API, only asynchronous writes can occur (synchronousWrites="true"   
245.        is ignored). By default this value is false (i.e. clustered caches use normal   
246.        Terracotta WRITE locks). * coherent=true|false - indicates whether this cache   
247.        should have coherent reads and writes with guaranteed consistency across   
248.        the cluster. By default, its value is true. If this attribute is set to false   
249.        (or "incoherent" mode), values from the cache are read without locking, possibly   
250.        yielding stale data. Writes to a cache in incoherent mode are batched and   
251.        applied without acquiring cluster-wide locks, possibly creating inconsistent   
252.        values across cluster. Incoherent mode is a performance optimization with   
253.        weaker concurrency guarantees and should generally be used for bulk-loading   
254.        caches, for loading a read-only cache, or where the application that can   
255.        tolerate reading stale data. This setting overrides coherentReads, which   
256.        is deprecated. * copyOnRead=true|false - indicates whether cache values are   
257.        deserialized on every read or if the materialized cache value can be re-used   
258.        between get() calls. This setting is useful if a cache is being shared by   
259.        callers with disparate classloaders or to prevent local drift if keys/values   
260.        are mutated locally w/o putting back to the cache. NOTE: This setting is   
261.        only relevant for caches with valueMode=serialization Simplest example to   
262.        indicate clustering: <terracotta/> To indicate the cache should not be clustered   
263.        (or remove the <terracotta> element altogether): <terracotta clustered="false"/>   
264.        To indicate the cache should be clustered using identity mode: <terracotta   
265.        clustered="true" valueMode="identity"/> To indicate the cache should be clustered   
266.        using incoherent mode for bulk load: <terracotta clustered="true" coherent="false"/>   
267.        To indicate the cache should be clustered using synchronous-write locking   
268.        level: <terracotta clustered="true" synchronousWrites="true"/>  -->   
269.  
270.     <!--  Mandatory Default Cache configuration. These settings will be applied   
271.        to caches created programmtically using CacheManager.add(String cacheName).   
272.        The defaultCache has an implicit name "default" which is a reserved cache   
273.        name.  -->   
274.     < defaultCache  maxElementsInMemory ="0"  eternal ="false"   
275.        overflowToDisk ="true"  timeToIdleSeconds ="1200"  timeToLiveSeconds ="1200" >   
276.  
277.     </ defaultCache >   
278.  
279.     <!--  Sample caches. Following are some example caches. Remove these before   
280.        use.  -->   
281.  
282.     <!--  Sample cache named sampleCache1 This cache contains a maximum in memory   
283.        of 10000 elements, and will expire an element if it is idle for more than   
284.        5 minutes and lives for more than 10 minutes. If there are more than 10000   
285.        elements it will overflow to the disk cache, which in this configuration   
286.        will go to wherever java.io.tmp is defined on your system. On a standard   
287.        Linux system this will be /tmp"  -->   
288.     < cache  name ="sampleCache1"  maxElementsInMemory ="10000"   
289.        maxElementsOnDisk ="1000"  eternal ="false"  overflowToDisk ="true"   
290.        diskSpoolBufferSizeMB ="20"  timeToIdleSeconds ="300"  timeToLiveSeconds ="600"   
291.        memoryStoreEvictionPolicy ="LFU"   />   
292.  
293.  
294.     <!--  Sample cache named sampleCache2 This cache has a maximum of 1000 elements   
295.        in memory. There is no overflow to disk, so 1000 is also the maximum cache   
296.        size. Note that when a cache is eternal, timeToLive and timeToIdle are not   
297.        used and do not need to be specified.  -->   
298.     < cache  name ="sampleCache2"  maxElementsInMemory ="1000"  eternal ="true"   
299.        overflowToDisk ="false"  memoryStoreEvictionPolicy ="FIFO"   />   
300.  
301.  
302.     <!--  Sample cache named sampleCache3. This cache overflows to disk. The   
303.        disk store is persistent between cache and VM restarts. The disk expiry thread   
304.        interval is set to 10 minutes, overriding the default of 2 minutes.  -->   
305.     < cache  name ="sampleCache3"  maxElementsInMemory ="500"  eternal ="false"   
306.        overflowToDisk ="true"  timeToIdleSeconds ="300"  timeToLiveSeconds ="600"   
307.        diskPersistent ="true"  diskExpiryThreadIntervalSeconds ="1"   
308.        memoryStoreEvictionPolicy ="LFU"   />   
309.  
310.     <!--  Sample Terracotta clustered cache named sampleTerracottaCache. This   
311.        cache uses Terracotta to cluster the contents of the cache.  -->   
312.     < cache  name ="sampleTerracottaCache"  maxElementsInMemory ="1000"   
313.        eternal ="false"  timeToIdleSeconds ="3600"  timeToLiveSeconds ="1800"   
314.        overflowToDisk ="false" >   
315.  
316.  
317.     </ cache >   
318.  
319.     <!--  Sample xa enabled cache name xaCache  -->   
320.  
321.     < cache  name ="xaCache"  maxElementsInMemory ="500"  eternal ="false"   
322.        timeToIdleSeconds ="300"  timeToLiveSeconds ="600"  overflowToDisk ="false"   
323.        diskPersistent ="false"  diskExpiryThreadIntervalSeconds ="1" >   
324.  
325.     </ cache >   
326.  
327.  
328. </ ehcache >   

操作类实例

01 . package com.rx;
02 . 
03 . import java.io.Serializable; 
04 . 
05 . import net.sf.ehcache.Cache; 
06 . import net.sf.ehcache.CacheManager; 
07 . import net.sf.ehcache.Element; 
08 . 
09 . public class EhCache { 
10 . 
11 .    /**  
12.     * @param args 
13.     */  
14 .    public static void main(String[] args) { 
15 .        System.out.println( 1 ); 
16 .        // CacheManager manager = new CacheManager(); 
17 . 
18 .        CacheManager singletonManager = CacheManager.create(); 
19 .        Cache memoryOnlyCache = new Cache( " testCache " , 5000 , false , false , 5 , 2 ); 
20 .        singletonManager.addCache(memoryOnlyCache); 
21 .        Cache cache = singletonManager.getCache( " testCache " ); 
22 . 
23 .        Element element = new Element( " key1 " , " value1 " ); 
24 .        cache.put(element); 
25 .        cache.put( new Element( " key1 " , " value2 " )); 
26 . 
27 .        element = cache.get( " key1 " ); 
28 .        Serializable value = element.getValue(); 
29 .        System.out.println(value); 
30 . 
31 .        int elementsInMemory = cache.getSize(); 
32 .        System.out.println(elementsInMemory); 
33 . 
34 .        long elementsInMemory2 = cache.getMemoryStoreSize(); 
35 .        System.out.println(elementsInMemory2); 
36 . 
37 .        Object obj = element.getObjectValue(); 
38 .        cache.remove( " key1 " ); 
39 .        System.out.println(obj); 
40 .        singletonManager.shutdown(); 
41 .        // manager.shutdown(); 
42 . 
43 .        System.out.println( 2 ); 
44 . 
45 .    } 
46 . 
47 .} 

转自： http://blog.csdn.net/longronglin/article/details/6699641

名称: ♪4C.ESL | .↗Evon
口号: 遇到新问题♪先要寻找一个方案乄而不是创造一个方案こ
mail: 联系我