I'm trying to solve the same problem. I'm amazed at how few articles talk about this issue. I've scoured the internet looking for tips on how to handle this. But it seems everybody assumes that all updates to the database are done through your EJB and thus you know when to reload the data.
In our case, we cache a lot of data to improve the performance of our application. There are somethings (like System Messages) that we'd like to trigger from an Admin GUI. Once triggered, we'd like our Read Only Entity Beans to go back to the database and refresh themselves. The database changes may happen outside of our application. So the Admin GUI would just trigger the refresh.
It would be easy enough to implement the CachingHome interface described below. But once you notified the bean to invalidate(), can you manually call EJBLoad() and force a refresh?
> Is it possible to manually invalidate a 'read-only'
> entity bean in a single server environment? Let me
> give some context to this...
> Weblogic automatically forces all entity beans to
> implement CachineHome, which is a special home
> interface with an invalidate() method that allows
> manual invalidation, and I just want to know if JBoss
> has something similar.
You can use the commit-option D with a refresh-rate defined. Sure its not the perfect solution for your problem . THis option lets you flush the cache at the defined refresh-rate. The problem is you cannot invalidate it when you need it!!
You can use the 'seppuku' pattern where you implement an invalidate() method as part of your beans business interface and from within this method throw a RuntimeException. The spec mandates that the bean instance in this case must be removed, forcing a resync with the database once you attempt to access an entity with the same primary key again.
In 3.2 it is possible to use a cache invalidation service. This is described in section 8 of the JBoss Clustering documentation.
Commit option D is also valid approach to reduce the load on your database, and involves the least amount of work on your part.
None of these approaches forces your beans to implement any specific interfaces from the JBoss application server.