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.
That could be one way, though I'd expect a single cachingTier element instead. Also, btw, as of today, it's an overflow model between the two "CachingTier". Having a single cachingTier that is itself defined in terms of 2 (or more) tiers, would also let you configure how these 2 would interact. Basically, you'd have some config bit within the cacheTier element that your provider would know how to understand (well not really the provider itself, but let me not go into details here ;) Will resume work on this soon I think. You'll get it then)