Hi jbrites,
I use this fragment for full eviction between unit tests.
Code:
Map<String, CollectionMetadata> allCollectionMetadata = sessionFactory.getAllCollectionMetadata();
for (String name : allCollectionMetadata.keySet()) {
sessionFactory.evictCollection(name);
}
Map<String, CollectionMetadata> allClassMetadata = sessionFactory.getAllClassMetadata();
for (String name : allClassMetadata.keySet()) {
sessionFactory.evictEntity(name);
}
sessionFactory.evictQueries();
The warning in the docs is about isolation (the I in ACID): in same cases it could be possible for your application to "notice" the eviction, so that a first lookup returns the value from the cache, while a second one could return another one or change tha values of the previous instance or have problems with locking version numbers, etc. (I do not know which case is actually possible and when). In other words eviction is NOT transactional so queries results could change in different invocations and so on.
I think the session cache (first level cache) mitigate this risk but something could slip through (especially with queries).
If you have very strong transactional requirements do not do this (and do not use EhChace, BTW). Otherwise this should not be a big problem, unless you do something like to schedule an evict every N minutes to fetch data written from an external process. In this last case I expect the risk to be higher.
I think a more correct approach for cache refresh should be to issue some big queries with CacheMode.REFRESH to refresh the data (maybe fetching more data than the maximum size of the cache...). I suppose, but not for sure, this should be 100% safe if you are using a transactional cache like JBoss Cache.
Login
FAQ
Search
