Summary |  Admin |  Home Page |  Forums |  Tracker |  Bugs |  Support |  Patches |  RFE |  Lists |  Tasks |  Docs News |  CVS |  Files
For Version 1.1
Frequently Asked Questions


Does ehcache run on JDK1.3?

Yes. It runs on JDK1.2, 1.3, 1.4 and 5. The restriction for JDK1.3 and JDK1.2 is that you must either use the precompiled ehcache.jar or build it using JDK1.4. This is because ehcache makes use of some JDK1.4 features but substitutes alternatives at runtime if it does not find those features.

Can you use more than one instance of ehcache in a single VM?

Not really.  CacheManager is a singleton. Singletons are per class loader. You could theoretically do it using two class loaders. You would need to have separate ehcache.xml files specifying a different diskStore path and load them each of the configuration files by name. See CacheManager.create(String configurationFileName) or one of the other create methods. 

You do not need to do this however. Ehcache can supports hundreds of caches within one instance.

Can you use ehcache with Hibernate and outside of Hibernate at the same time?

Yes. You use 1 instance of ehcache and 1 ehcache.xml. You configure your caches with Hibernate names for use by Hibernate. You can have other caches which you interact with directly outside of Hibernate.

That is how I use ehcache in the original project it was developed in. For Hibernate we have about 80 Domain Object caches, 10 StandardQueryCaches, 15 Domain Object Collection caches.

We have around 5 general caches we interact with directly using BlockingCacheManager. We have 15 general caches we interact with directly using SelfPopulatingCacheManager. You can use one of those or you can just use CacheManager directly.

I have updated the documentation extensively over the last few days. Check it out and let me know if you have any questions. See the tests for example code on using the caches directly. Look at CacheManagerTest, CacheTest and SelfPopulatingCacheTest.

What happens when maxElementsInMemory is reached? Are the oldest items are expired when new ones come in?

When the maximum number of elements in memory is reached, the least recently used ("LRU") element is removed. Used in this case means inserted with a put or accessed with a get.

If the overflowToDisk cache attribute is false, the LRU Element is discarded. If true, it is transferred asynchronously to the DiskStore.

Is it thread safe to modify Element values after retrieval from a Cache?

Remember that a value in a cache element is globally accessible from multiple threads. It is inherently not thread safe to modify the value. It is safer to retrieve a value, delete the cache element and then reinsert the value.

The UpdatingCacheEntryFactory does work by modifying the contents of values in place in the cache.  This is outside of the core of ehcache and is targeted at high performance CacheEntryFactories for SelfPopulatingCaches.

Can non-Serializable objects be stored in a cache?

No. Both keys and values must be Serializable. The reason is they must be Serializable to be persisted to the DiskStore.  If the type was Object and not Serializable, runtime UnserializableExceptions would be thrown when an Element is transferred to the DiskStore.

As it is now, your keys and values must be Serializable or you will get a compile-time error.

Why is there an expiry thread for the DiskStore but not for the MemoryStore?

Because the memory store has a fixed maximum number of elements, it will have a maximum memory use equal to the number of elements * the average size. When an element is added beyond the maximum size, the LRU element gets pushed into the DiskStore.

While we could have an expiry thread to expire elements periodically, it is far more efficient to only check when we need to. The tradeoff is higher average memory use.

The DiskStore's size is unbounded. The expiry thread keeps the disk store clean. There is hopefully less contention for the DiskStore's locks because commonly used values are in the MemoryStore. We mount our DiskStore on Linux using RAMFS so it is using OS memory. While we have more of this than the 2GB 32 bit process size limit it is still an expensive resource. The DiskStore thread keeps it under control.

If you are concerned about cpu utilisation and locking in the DiskStore, you can set the diskExpiryThreadIntervalSeconds to a high number - say 1 day. Or you can effectively turn it off by setting the diskExpiryThreadIntervalSeconds to a very large value.

What elements are mandatory in ehcache.xml?

The documentation has been updated with comprehensive coverage of the schema for ehcache and all elements and attributes, including whether they are mandatory. See the Declarative Configuration chapter.

Can I use ehcache as a memory cache only?

Yes. Just set the overflowToDisk attribute of cache to false.

Can I use ehcache as a disk cache only?

Yes. Set the maxElementsInMemory attribute of cache to 0.

This is strongly not recommended however. The minimum recommended value is 1. Performance is as much as 10 times higher when to one rather than 0. If not set to at least 1 a warning will be issued at Cache creation time.

Where is the source code?

The source code is distributed in the root directory of the download. It is called ehcache-x.x.zip. It is also available from SourceForge online or through cvs.

How do you get statistics on an Element without affecting them?

Use the Cache.getQuiet(Serializable key) method. It returns an Element without updating statistics.

How do you get WebSphere to work with ehcache?

It has been reported that IBM Websphere 5.1 running on IBM JDK1.4 requires commons-collection.jar in its classpath even though ehcache will not use it for JDK1.4 andJDK5.

Do you need to call  CacheManager.getInstance().shutdown()  when you finish with ehcache?

Yes, it is recommended. If the JVM keeps running after you stop using ehcache, you should call CacheManager.getInstance().shutdown() so that the threads are stopped and cache memory released back to the JVM. Calling shutdown also insures that your persistent disk stores get written to disk in a consistent state and will be usable the next time they are used.

If the CacheManager does not get shutdown it should not be a problem. There is a shutdown hook which calls the shutdown on JVM exit. This is explained in the documentation here.

Can you use ehcache after a CacheManager.shutdown()?

Yes. When you call CacheManager.shutdown() is sets the singleton in CacheManager to null. If  you try an use a cache after this you will get a CacheException.

You need to call CacheManager.create(). It will create a brand new one good to go. Internally the CacheManager singleton gets set to the new one. So you can create and shutdown as many times as you like.

There is a test which expliciyly confirms this behaviour. See CacheManagerTest#testCreateShutdownCreate()



SourceForge.net