It depends on how you have the timer thread/service/whatever deployed. If you have one running for every server in the cluster, then yes, it will be an issue.
What we did, is only have ONE server run the timer thread/service, so they only get run from one source to ensure there is no cluster mixing
Thanks for the info.
Yes, we would like to have the timer thread (servlet) running on each machine in the cluster. It seems like the simplest approach.
When you say we will be in trouble doing this, are you doing so in the context of 3.2? It looks like the issue is being addressed in JobExecutorThread. acquireJobs() using Hibernate and transactional locking, but we would like to be certain.
In jBPM 3.1, multiple scheduler threads query and execute timers without synchronization, leading to duplicate executions.
In 3.2, this issue is effectively being addressed through a lock mechanism at the database level. You should be able to run multiple job executor threads. This mechanism is still under test, tough. Let us know if you find any problem.
If using an ejb timer, what happens if one node goes down? My expericence is if still have any running nodes, the timers local to the failed node will not be picked up, since timer is local.
If it is true, ejb timer approach for jbpm is really in trouble.
Also, following problems:
1. Timer can not get picked up after jboss restarts.
The TimerServiceBean jndi name keeps changing between jboss restarts. Then the old timer with obosolete timers.targetid will be ignored. Have to change the local jndi name to fix it. Although it is not a big deal, but the jbpm-enterprise.ear will not work without this change.
2. The timer is created with no interval, so it will only execute once, so I have to change the code to do it better.
Are these the real problems or just my imagination?
Also improvements I like to have:
1. procesdefinition deployment is a pain. I have to write some servlet listener to kludge the version checking. How difficult we do it at system level - do not deploy if the definition already exists?
2. how to achieve the pooling of async execution? only way I know of is to limit the TimerServiceBean pool size. But it is clumsy. Ideally it can have different delay queues, so we can treat normal executions and retries differently, say with different intervals.
@supterlobster: would you explain, what changes you made? Thanks.
I got the same problem with ejb timer (can not get picked up after jboss restarts). After adding the SLSB to jboss.xml descriptor everything works fine.
Is there a cause, why this is not made out-of-the-box?
>Is there a cause, why this is not made out-of-the-box?
I do not know. Maybe the example just tested on the hypersonic db. Anything else is fun for your own exploration.