Creates a simple cache, heap only. Capacity eviction all up to the Cache(Manager)?
<ehcache:cache alias="countries"> <!--(1)-->
<ehcache:key-type>java.lang.String</ehcache:key-type> <!--(2)-->
<ehcache:value-type>com.pany.model.Country</ehcache:value-type> <!--(3)-->
</ehcache:cache>
-
Creates a cache, available as 'countries' from the CacheManager
-
Sets the FQCN for the key type
-
Sets the FQCN for the value type
Key/Value type is persisted if this would be a persistent cache.
Note
|
The fact that this creates a heap only cache is dictated by the default provider used to create this cache, see below |
<ehcache:cache alias="countries">
<ehcache:key-type>java.lang.String</ehcache:key-type>
<ehcache:value-type>com.pany.model.Country</ehcache:value-type>
<ehcache:store provider="org.ehcache.store.OffHeapStoreProvider" /> <!--(1)-->
</ehcache:cache>
-
Adding the store element and specifying the optional provider attribute, lets the user be more specific about what store implementation to use. Here we make it use a OffHeapStore directly, bypassing heap entirely
<ehcache:cache alias="users">
<ehcache:key-type>java.lang.String</ehcache:key-type>
<ehcache:value-type>com.pany.model.User</ehcache:value-type>
<ehcache:store> <!--(1)-->
<ehcache:cachingTier provider="org.ehcache.tiering.HeapCacheProvider"/> <!--(3)-->
<ehcache:authority provider="org.ehcache.tiering.OnDiskAuthority"/> <!--(2)-->
</ehcache:store>
</ehcache:cache>
-
Optional store element, provider auto-resolved from the "packaged" here, lets someone specify how the tiering of a Cache is to be configured
-
The AuthoritativeTier holds all the data at all times; here all data is on disk.
-
Above the authority, the CachingTier holds a smaller subset of the data, closer to the app; here on-heap.
<ehcache:store>
<ehcache:cachingTier provider="org.ehcache.tiering.HeapCacheProvider">
<ehcache:someConfig maxElements="1000"/> <!--(1)-->
</ehcache:cachingTier>
<ehcache:authority provider="com.pany.ehcache.CacheAuthority">
<foo:foo>12</foo:foo> <!--(2)-->
</ehcache:authority>
</ehcache:store>
</ehcache:cache>
-
Some default sizing config, probably both count and byte based
-
Config is extensible, here some random foo config is passed to the custom CacheAuthority provider configured in the standard config
Services are merely lifecycled by the CacheManager. But are a powerful extension mechanisms to Ehcache.
<ehcache:config
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns:foo='http://www.example.com/foo' <!--(1)-->
xmlns:ehcache='http://www.ehcache.org/v3'
xsi:schemaLocation="http://www.example.com/foo foo.xsd">
<ehcache:service> <!--(2)-->
<foo:foo/> <!--(3)-->
</ehcache:service>
<!-- Cache configs -->
</ehcache:config>
-
Declare a namespace that is unique to your service
-
Declare an Ehcache service
-
Configure it using your own configuration (nothing imposed by Ehcache here)
Ehcache will use the Java ServiceLoader API to find XmlConfigurationParser<T extends Service> implementation that is capable of configuring a service for the namespace (used within the service element, in this example above \http://www.example.com/foo).
Services can then be referenced and used from other custom configured components.
Would the following represent a heap / off-heap / disk tiered cache?