Q: How to programatically "evict" from the 2nd level cache, all the classes attached to a given "cache region"?

From the SessionFactory object I can get the list of the classes defined in the configuration file (getAllClassmeteData() and their ClassmetaData) but I don't see any mean to retrieve the name fo the classes attached to a given region in the configuration file. The ClassMetaData does not have any information related to the caches)

I would like to get the list of all the classes defined in the configuration file with the <class-cache region="..> tags and then loop around an "SessionFactory.evict(class)" to purge the second level cache from those entities.

Is there a way to get this list from the SessionFactory object?

Of course I can parse myself the configuration file, but this is quite hugly and I'm sure this information si somewhere in the application context...

The best would be to have a SessionFactory.evictRegion(regionName) method...

thx

For each class you can get a reference to its EntityPersister (SessionFactory.getEntityPersister(...)) which gives you CacheConcurrencyStrategy instance (EntityPersister.getCache()) which has the region name and it also lets you clear that region. You may have to write a utility class that uses all this information to do what you want to do. In any events, why would you like to do that?



Farzad-

Thanks!! I will give it a try

Why?
Because we have a set of tables considered as 'read-only" in the web application. Those tables are mostly reference tables.
Most of those read-only referenced tables are grouped in a single region of the second-level cache (strategy=read-only) . The cache can handle all the content of those tables.

Those tables are refreshed each night, ie re-loaded with a database "import" command (db2 import).
.
So, after those tables are refreshed in the DB, we need to reset the Hibernate second-level cache for the web application and as I don't want to duplicate the information that keeps the list of the tables currently assigned to this cache-region, (ie "<cache-table" tags ), I need from the configuration file/metadata, the list of tables using this specific cache region.

I will build the list of table attached to the given region once at application statup.

FYI, we use WebSphere v6.1 in a cluster with 2LC replication implemented via the DistributedMap feature of WebSphere and the cache refresh trigger is done via a basic http get handled by a seam action.

And as I sad in my initial post, the ideal solution would to add a method called SessionFactory.evictRegion(regionName) ...

My understanding is that in these scenarios you will need to set a time to live for a cache region. In your case a 24h will do and you won't need to clear the static cache region manually. That should save you the hassle.


Farzad-

This would not work:
- The batch that load data may be late...
- To my understanding, the "time to live" set the time a given object will stay in the cache. if the object is loaded in the 2LC 5 minutes before the corresponding table is reloaded, the data will be wrong for the next 23h55 because the object will be purged from the cache 24h later...With a long period of high risks of inconsistencies between refreshed tables.
- a workaround would be to preload all the content of those tables in the cache after the load and after the time-to-live expired.... but we'll have to develop some code to do and need to execute that code at the right time. How to synchronise the preload with the cache expiration event?

Definitevely, I think my solution is the more robust and easiest to implenment

thx for your help
BTW.. We are in montreal too..lol

I still feel a little creepy about going through hibernate API to do this. My own preference is to set the time to live to something that would work for you unless you are expecting 24h user interaction like in case of an online shopping software. The time does not really have to be very large. Even every hour refresh rate in many cases is a good refresh time with minimal performance impacts. At the same time, I understand this might be much more critical than what I am projecting here and a robust solution would be inevitable.

Anyhow, it's nice to know a Montreal dude.

Respect
Farzad-