2 Replies Latest reply on Sep 12, 2008 7:33 AM by wdfink

    EJB3 timer and cluster behaviour (JBoss 5.0.0)

    wdfink

      I know that the ejb2 timer with JBoss 3.x/4.x is not really cluster aware.

      How the new ejb3-timer-service manage the timers in a clustered environment.
      Are the timer-events syncronized via database that a single execution of a timeout is ensured ?

      Anybody who know this?

        • 1. Re: EJB3 timer and cluster behaviour (JBoss 5.0.0)

          Hi wdfink
          I recently implemented the exact same thing with JBoss EAP v4.2-CP02.

          http://docs.jboss.org/jbossas/jboss4guide/r4/html/cluster.chapt.html#clustering-jms-loadbalanced

          I did the following:
          On each JBoss machine, replaced DefaultDS to a real, external database. By default, JBoss uses HSQLDB internally, and ofcorse, this is not common between multiple instances of JBoss on different machines. See section 16.6.1.1 of the above doc for instructions on how to do this.

          In the jboss.xml of my war file, i added:

          <message-driven>
           <ejb-name>BlahMDB</ejb-name>
           <depends>jboss.ha:service=HASingletonDeployer,type=Barrier</depends>
           </message-driven>
          


          I then deploy the ear file containing this war file to the farm directory.

          What I saw was that all clusters installed BlahMDB, but only one cluster actually started it, (and the assocated timers it has). I configured BlahMDB to tick every 30seconds, then create a new one, and tick 30seconds later. So, this timer was ticking on only one instance of the cluster.
          When i killed JBoss on that instance, the ticks would automagically resume on some other node in the cluster.

          Hope this helps!

          -Daniel.

          • 2. Re: EJB3 timer and cluster behaviour (JBoss 5.0.0)
            wdfink

            Hi Daniel,
            what you do is deploy the MDB as HASingleton and the timer will only have one server with this special MDB. But the timeout will happen for each node, because the TIMER-table is the same for all.

            What I need is a real cluster aware timer where a SLSB|MDB can create a timer and it is ensured within the hole cluster that this SLSB is only started once if the timer exceed, also if the SLSB|MDB is active at each cluster node.

            So your workaround didn't works for me.