EHC ❯ putWithWriter Throw an exception when no writer is registered
-
Bug
-
Status: Closed
-
2 Major
-
Resolution: Fixed
-
ehcache
-
-
gbevin
-
Reporter: pjaton
-
March 11, 2010
-
0
-
Watchers: 1
-
July 15, 2010
-
April 08, 2010
Description
According to the Javadoc of the new cache’s putWithWriter(Element) method:
Put an element in the cache writing through a CacheWriter. If no CacheWriter has been set for the cache, then this method has the same effect as cache.put().
However, when using this method without having any cache writer registered, the following exception is thrown. For consistency, it seems that the putWithWriter method should act as documented as this is how the getWithLoader method will behave when no loader is registered with the cache.
net.sf.ehcache.CacheException: Cache: visitorDomain was being used with cache writer features, but it wasn’t properly registered beforehand. at net.sf.ehcache.Cache.initialiseCacheWriterManager(Cache.java:1033) at net.sf.ehcache.Cache.putInternal(Cache.java:1165) at net.sf.ehcache.Cache.putWithWriter(Cache.java:1160) at com.localmatters.ds.dao.terracotta.ehcache.EhcacheWithWriteBehind.save(EhcacheWithWriteBehind.java:29) at com.localmatters.ds.dao.cache.CacheWithKeyGeneration.save(CacheWithKeyGeneration.java:27) at com.localmatters.ds.dao.cache.CacheWithKeyGeneration.save(CacheWithKeyGeneration.java:14) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at com.localmatters.util.hotswap.HotSwappingInvoker.invoke(HotSwappingInvoker.java:35) at $Proxy37.save(Unknown Source) at com.localmatters.ds.dao.cache.VisitorDaoCache.saveVisitorDomain(VisitorDaoCache.java:196) at com.localmatters.ds.dao.cache.VisitorDaoCache.saveVisitor(VisitorDaoCache.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at com.localmatters.util.hotswap.HotSwappingInvoker.invoke(HotSwappingInvoker.java:35) at $Proxy38.saveVisitor(Unknown Source) at com.localmatters.ds.persistence.DefaultPersistenceControllerImpl.saveVisitor(DefaultPersistenceControllerImpl.java:183) at com.localmatters.ds.service.DefaultVisitorDomainServiceImpl$2.doInTemplate(DefaultVisitorDomainServiceImpl.java:148) at com.localmatters.mvc.domain.DomainTemplate.execute(DomainTemplate.java:48) … 69 more
Comments
Geert Bevin 2010-03-12
Patrice Jaton 2010-03-12
I can see your point in some cases. I guess what I am trying to do is to have a clean separation of concern about the client of the cache and how the cache is configured, whether it is distributed or not has a write-behind persistence, etc.
This is important in our application, because these are consideration that might change from one of our client to another and I might be quite some work to have to adapt the code for concerns that seems to me to be of the cache, not the client of the cache. I guess, I can always encapsulate the calls to the cache into a family of classes that we can then swap depending on the expected behavior we are looking for.
Maybe we could agree on an in-between approach. It feels to me that the danger might occurs in the case where a cache writer has been configured for a cache, but is never registered. Could this fact (has been configured) be the triggered of the exception? In order words, wouldn’t it make sense to throw an exception if a client calls “putWithWriter” on a cache that has been configured to have a cache writer, but no cache writer was ever registered and be silent if no cache configuration has been set on the cache?
Geert Bevin 2010-03-13
That could work, I’ll have to talk this over internally to see if others are ok with this. I think that it would indeed be a good middle ground. I’ll keep you posted.
Fiona OShea 2010-04-08
Fixed by Geerts additions to Javadocs
I personally beg to differ. I think it’s very dangerous to risk doing puts without them being seen by a writer as this is often used for critical operations. With the exception being thrown, people can still catch it and act accordingly.
putWithWriter silently returning has the risk of people losing data, this is very different from getWithLoader just not populating the cache. I think we should change the javadoc.