My first thought would be ehcache all the stuff in front end with a reasonable expiration period (hours maybe), and then expose a very simple JMX interface to manually reset the cache without bouncing the entire app. No need to send much data over JMX other than just a simple 'refresh all caches' command. Pretty simple, but gives you a lot of options.
Good luck On Fri, Feb 3, 2012 at 2:51 PM, Bas Gooren <b...@iswd.nl> wrote: > Hi All, > > Maybe a fellow wicketeer can help me with this: > > We deploy one of our apps in two components: a frontend and an admin. We > recently implemented a StringResourceLoader which fetches translations from > a database. > So far so good. > > Now we face the following problem: the frontend uses this > StringResourceLoader, but the actual translations are managed through the > admin. > > Currently both apps are deployed on the same vm (and in the same tomcat > instance), but this might change in the future. > We need a mechanism to tell the frontend to flush the localizer (and > StringResourceLoader) cache when the user clicks a button in the admin. > > After some investigation we've found a number of solutions, ranging from > easy to complex: > - cross context = true, share a boolean through the ServletContext and > poll for it to change > - have the frontend expose an MBean (JMX) which the admin can control > - use a message bus for communication (e.g. rabbitmq) > - cluster communication, such as jgroups or hazelcast > > Can anyone comment on this? I'd prefer to keep things simple at this stage > (e.g. setting up an external message bus for this seems overkill), but > having something which works as we scale out would be preferable. > > Sebastian >
