How to configure a default XML template (EHCache v 3)

1,856 views
Skip to first unread message

Igor Polevoy

unread,
Dec 9, 2015, 12:53:00 PM12/9/15
to ehcache-users
It is my understanding, that the alias "simpleCache" in the XML file: 


  <cache-template name="myDefaults"> 
    <key-type>java.lang.Long</key-type>
    <value-type>java.lang.String</value-type>
    <heap size="200" unit="entries"/>
  </cache-template>

  <cache alias="simpleCache" uses-template="myDefaults" />

is the same alias you need to provide when creating cache based on this configuration: 

cacheManager.createCache("simpleCache", ...);


In my project, the cache name is determined at run time, meaning I cannot code it in the XML file. 

I have two questions: 

1. Is there  a way to configure a default cache configuration?
2. How to create a Cache instance with dynamic name, but based on default configuration from #1 ? 

Thanks
igor

Louis Jacomet

unread,
Dec 9, 2015, 1:16:49 PM12/9/15
to ehcache-users
Hi Igor,

In your example, a cache named simpleCache will be created upon CacheManager initialization, no need to create it. Actually, it is illegal to try to create it.

For the other points:
  1. There is currently no concept of "default" cache configuration
  2. Not possible
Templates do provide a way to work around the limitation. I believe the other thread on this topic may have answered it though.

Regards,
Louis

--
You received this message because you are subscribed to the Google Groups "ehcache-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ehcache-user...@googlegroups.com.
To post to this group, send email to ehcach...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-users/5eb91dde-3b0a-441b-9646-266437759aaf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Igor Polevoy

unread,
Dec 9, 2015, 9:04:09 PM12/9/15
to ehcache-users
Louis, thanks for the answer. Unfortunately I'm not getting closer to my goal. I'm the main author of JavaLite: http://javalite.io. 
One component is an ORM called ActiveJDBC: http://javalite.io/activejdbc. 

It has caching built-in:  http://javalite.io/caching and relies on third party caching, including EHCache: http://javalite.io/caching#ehcache-configuration
As you can see, the current implementation relies on EHCache v2. 

All want is to upgrade it to EHCache v3. I have been banging my head on the keyboard for three days now, but still cannot figure out how to do this. 
The API changed, and docs are not completed yet. 

Since JavaLite is a product, and not a project, I need to keep EHCache configuration external to my code (XML, not Java). 
This means that the XML file needs to provide default  values for creating caches.

In addition to that, because this is an ORM, the data is stored in cache per each table. In v.2, I could specify default properties for all caches:

In code, I create a Cache instance per table, and store data in that cache. When I need to flush a cache, I delete the object and create a new one.

Is there a way to do this in in v3? 


But I still do not know how to ensure that a new cache will be created based on XML configuration. 


Any help is appreciated!

thanks
Igor

Alex Snaps

unread,
Dec 10, 2015, 12:57:41 PM12/10/15
to ehcache-users
Hey Igor, 
I'm not sure where the issue lies. In Ehcache 2.x you used "default" caches as the basic template for all the Cache instances your library creates, y?
If so, you actually did require the user to configure that "defaultCache" in the ehcache.xml, y?
Since there is no "defaultCache" in the 3.x line anymore, you just need to either:
 - Ask the user to configure a given cache-template in his ehcache.xml
 - Have the name of the template to use, dynamically configurable at your library's level

You probably already have ways for the user to configure what CacheManager to use (the singleton one, or a specific one) and/or where to find the XML file. I think this kind of potentially additions to the config would go along these existing one. 

The second part about "deleting an object", I'm unsure what you mean. Removing the Cache from the CacheManager and replace it with another one? If so, then yes... 
Alex 
 

To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-users/beab6166-96ab-46b6-af86-be5761e1d29f%40googlegroups.com.

Igor Polevoy

unread,
Dec 10, 2015, 1:19:18 PM12/10/15
to ehcache-users
Alex, thanks for advice. It is my understanding, that if you create a cache, and no configuration is provided in XML, it still has some configuration, correct? 
If this is the case, where is this configuration coming from?

Also, please, see my responses below. 

Thank you
Igor 


On Thursday, December 10, 2015 at 11:57:41 AM UTC-6, Alex Snaps wrote:
Hey Igor, 
I'm not sure where the issue lies. In Ehcache 2.x you used "default" caches as the basic template for all the Cache instances your library creates, y?

Correct!
 
If so, you actually did require the user to configure that "defaultCache" in the ehcache.xml, y?

Correct!
 
Since there is no "defaultCache" in the 3.x line anymore, you just need to either:

This is REALLY unfortunate. Are there plans to bring defaults back? 

 
 - Ask the user to configure a given cache-template in his ehcache.xml

This is not practical. My ORM stores cached data for each database table   in a separate Cache object. This is done so that in case there is INSERT/DELETE/UPDATE operation on that table, I could just kill the Cache object to avoid logical errors 

Creating configurations for each table means having many blocks of identical code in the XML file, with name being the only difference! In my current project, we have 120 tables. Does this mean that XML file will balloon to 120 chunk of ugly identical XML? 

Besides, ActiveJDBC philosophy is "no configuration". In fact, today the EHCache 2 XML file is the only config file necessary for ActiveJDBC to with (if cache is enabled). If a developer does not need a cache, then ActiveJDBC ORM works without any configuration.

As such, asking users to copy/paste XML every time they add a new table in the database is .. not smart. 


 - Have the name of the template to use, dynamically configurable at your library's level


As I mentioned above, this is a no-configuration library. 

Alex Snaps

unread,
Dec 10, 2015, 1:28:28 PM12/10/15
to ehcache-users
No, the default as such will never come back. But if you expected the user to configure that cache, then he may just as well configure some agreed on template instead... it's the exact same contract as with the default cache: the user was expected to configure that in the 2.x line.
I have a hard time seeing how having all tables use the same cache config makes sense though... 
That would NOT require to have a dedicated cache configuration per table though. You could use the same template to create as many cache instances as you'd want to. Just lookup the CacheConfiguration from the template's name (say "ActiveJDBC") and create the new Cache instance using that. 
More so, you could actually have a dedicated xml file for ActiveJDBC embedded so that even when using caching with Ehcache it would require no configuration. If sensible defaults can be found, you could just use these... Is your library OSS? Where is the source to be found, I probably could hack something quickly to show you how to achieve this using the new API. 
Alex



To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-users/8ac14724-8af7-44d1-a594-4553e96b01d8%40googlegroups.com.

Igor Polevoy

unread,
Dec 10, 2015, 3:35:27 PM12/10/15
to ehcache-users

Alex Snaps

unread,
Dec 10, 2015, 4:01:14 PM12/10/15
to ehcache-users
I didn't test any of what I just did, but you should get a grasp based on the PR I just created!
Hope this helps. Just comment on the PR or anything if you need more insights!
Alex

To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-users/06c0a8aa-7e58-4ca7-8882-8779e40094a0%40googlegroups.com.

Igor Polevoy

unread,
Dec 10, 2015, 4:23:33 PM12/10/15
to ehcache-users
Hi, Alex. this is great, thanks for the PR.  I ran all tests, and they are all green. 

I have one more  question remaining: 

On line 78, I basically say we do not support this feature (really need to throw exception). However, is there still away to implement it? 
Is there a way  to get a list of Cache objects, and close one at the time? I did not find such methods, but this class is called CacheManager  :). 


Thank you,

Alex Snaps

unread,
Dec 10, 2015, 4:30:46 PM12/10/15
to ehcache-users
You could do it like that:

            synchronized (lock) {
                for (Map.Entry<String, org.ehcache.config.CacheConfiguration<?, ?>> c : cacheManager
                    .getRuntimeConfiguration()
                    .getCacheConfigurations()
                    .entrySet()) {
                    final Cache<?, ?> cache = cacheManager.getCache(c.getKey(), c.getValue().getKeyType(), c.getValue()
                        .getValueType());
                    cache.clear();
                }
            }

That could clear other caches though. But given your code, the CacheManager isn't ever leaked... 
Don't think that synchronization isn't required though really... 
Sort of thinking out loud here.
Alex


To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-users/a7492e40-1fa7-462b-8621-ad1bc5ece49c%40googlegroups.com.

Igor Polevoy

unread,
Dec 10, 2015, 4:47:11 PM12/10/15
to ehcache-users
Alex, this is great. I will try this.

Thanks for helping out!
igor
Reply all
Reply to author
Forward
0 new messages