I've got a major fire here. Hoping someone can help me out.
We have a legacy app running on JBoss 3.2.5 using EJB. We started running a new version in parallel on the same database. The problem is that the older one is caching a lot of data in memory. So, some updates to the db made from version 2 are not being seen by version 1 and all kinds of bad things are happening.
I've googled on JBoss caching but can't find anything.. at least not for that version. Is there a simple switch or method I can use to force it to go back to the db and refresh data for all finders, etc? I realize this may hurt performance, but that's better than a hosed database.
OK, I've found some info on clustered caching. When an entity in one cluster is modified, it can send a message to the other nodes in the cluster that their cached data is now stale and to invalidate the cache accordingly.
If I could just figure out how to how to programaticaly replicate that process... that might do the trick.
Commit option A can boost your Entity Bean but what happens when running in a cluster ? in a cluster configuration more than one JBoss node will access the same database. Furthermore, they will not only read data, but may also update the db store.Consequently, we now have as many points of write access to the database as we have JBoss instances in the cluster.
For these scenarios, JBoss incorporates a handy tool: the cache invalidation framework. It provides automatic invalidation of cache entries in a single node or across a cluster of JBoss instances. As soon as an entity bean is modified on a node, an invalidation message is automatically sent to all related containers in the cluster and the related entry is removed from the cache. The next time the data is required by a node, it will not be found in cache, and will be reloaded from the database.
In order to activate it, add to your Entity Bean the cache-invalidation tag.