1 Reply Latest reply on Sep 9, 2009 9:57 AM by jaikiran pai

    Execute TimerService().createTimer() exactly once in a clust

    Paul Giblock Newbie

      Hello.

      First off, I've read the article at: http://www.jboss.org/community/wiki/DeployingEJB3TimersInCluster I now have a SLSB with an @Timeout which is deployed with:

      <depends>jboss.ha:service=HASingletonDeployer,type=Barrier</depends>


      The problem is, unlike the article linked above, I will not be starting the timers multiple times over the lifetime of the application. In my case, I want the timer to be started exactly once for the whole cluster.

      I previously had a ServletContextListener subclass where contextInitialized() would kill all timers and start them. The problem is, now if I have more nodes join the cluster, the timers are killed and recreated. Is there a better way to accomplish this?

      Additionally, I thought maybe I could start the Timer in the @PostConstruct of the SLSBs themselves. However, this fails with
      TimerService.getTimers should not be access from this bean method: IN_EJB_CREATE


      Any help regarding this is appreciated! Thanks.

        • 1. Re: Execute TimerService().createTimer() exactly once in a c
          jaikiran pai Master

           

          "pgib" wrote:

          I previously had a ServletContextListener subclass where contextInitialized() would kill all timers and start them. The problem is, now if I have more nodes join the cluster, the timers are killed and recreated. Is there a better way to accomplish this?


          I haven't tried it myself - but how about using a HASingleton @Service instead of the ServletContextListener?

          "pgib" wrote:

          Additionally, I thought maybe I could start the Timer in the @PostConstruct of the SLSBs themselves. However, this fails with
          TimerService.getTimers should not be access from this bean method: IN_EJB_CREATE




          As per the table in EJB3 spec, section 4.5.2 - methods on TimerService are not allowed to be invoked in the @PostConstruct of the bean.