2 Replies Latest reply on Aug 26, 2004 2:26 PM by Ivan O. Parra

    Resetting The Cache

    neva Newbie


      I have been reading for quite some time now about jboss caching configurations. I have a question however that I weren't able to answer on my own. What if, in my application, I need to reset all cached data when a specific event occures? (leave aside cache invalidation)

      I know that I can use the JMX console to flush cached data of a specific bean manually but how do I do it automatically (in other words, programmatically) for all beans in my application.


        • 1. Re: Resetting The Cache
          daeel Newbie

          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.

          • 2. Re: Resetting The Cache
            Ivan O. Parra Novice


            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.

            On-Demand(mid tx)
            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.

            Good luck,