First use JMX and twiddle to make a list of all local EJBs (I.e. in my case all the entities)
./twiddle.sh -s localhost:1299 invoke 'jboss:service=JNDIView' listXML | grep local | sort | uniq >flush.sh
Then edit flush.sh to include a flush command for each entity i.e.:
./twiddle.sh -s localhost:1299 invoke 'jboss.j2ee:jndiName=local/[YOUR_FIRST_ENTITY_NAME],plugin=cache,service=EJB' flush
./twiddle.sh -s localhost:1299 invoke 'jboss.j2ee:jndiName=local/[YOUR_SECOND_ENTITY_NAME],plugin=cache,service=EJB' flush
...and so on
then you could flush all the entity caches by ./flush.sh
Of course this could be improved a lot with more clever shell scripting the two commands above could be combined to always flush the deployed entites, then I guess it should be possible to do from Java as well, I'm looking into that now.
1) You'll need somesort of threshold that would define when to flush the cache
2) When that threshold is reached, use the JMX calls to flush the cache.
If you want to automate it, you could schedule a job or start your own MBean Service(a worker thread) that periodically checks the threshold.
For simplicity, develop a tool that uses the JMX layer to flush the cache. Depending on your expected response time to flush the cache, you may want to do it.
Soon(post to a MDB)
Convenience(background schedule thread)
For a large application, creating a backdoor with a special "Flush current state" may be a good idea. In that fashion, you can change your current configuration in many places without affecting the current running system. Then when everything is set/ready, you can push the "magic button" and the configuration becomes part of the application. I use to do this for online trading services to reroute trades without disrupting our live clients. It was seamless and effective.