
FAQ
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()
