you can configure jbpm to use JMS for this in a multi host Java EE environment easily. You can look in the jbpm-enterprise source code, there you find an example for EJB 2, but it can be easily adopted to EJB 3 (because of compatibility issues, jBPM 3 is is tied to Java 1.4).
Jms is not an option for us since we don't use it in our application. I also think a fairly straightward out of the box distributed scanner (which is fairly simple to implement) is preferable to requiring jms for distributed timers to work.
I am afraid I don't understand your problem neither your solution. What do you mean with 'jBPM runtime'? jBPM is a library, there is no runtime unless you write an application that uses the library (such as the servlet that kicks off the SchedulerThread).
Also, I don't understand your objections against JMS. To me this sounds like, 'using a JVM is no option because we don't use it, so we decided to write our own proprietary one'...
Am I missing something?
Using JMS requires JMS provider which not everybody wants to use. Especially if your application doesn't already use it. For example in our scenario (a distributed application) this would require setting up a central broker, something like ActiveMQ or WebSphere MQ, etc. Obviously, this is a lot of overhead for just getting timers to work.
As for my proposal, there's nothing proprietary about it - it simply involves making changes to the SchedulerThread to use proper DB locking (for example using LockMode.UPGRADE_NOWAIT before executing the timer). This will prevent multiple hosts from picking up the same Timer.
As to the runtime - I was simply referring to JBPM engine. Instead of relying on servlet.init() to kick start SchedulerServlet, which will only work in J2EE environments, I propose having jbpm itself start the thread. For example, when JbpmConfiguration is initialized it can start the thread. This is not a big deal for us, I was just making a comment since I'm sure there are people who do not run JBPM in J2EE environment.
Hope this makes more sense.
afaik, the job executor threads first try to write their name in a job before they execute it. that update should be guarded with optimistic locking. if multiple threads try to do this at the same time, all but one should get an exception and they have to rollback. i think this requires READ_COMMITTED as hibernate optimistic locking requires isolation level READ_COMMITTED on the jdbc connections.
so please be more specific to the problem in the current code and what changes you want to apply and why.
the LockMode.UPGRADE_NOWAIT is not preferred as not all databases support LockMode.UPGRADE. that is why we opted for optimistic locking instead.
Regardless of the locking issues...
The first E in JEE stands for enterprise. If people do not use JEE but want e.g. clustering, loadbalancing, whatever.. we (or anyone) should not try to build something around it. History learned me that it, in hindsight, is always to minimalistic and before you know it, there is this home grown not-called-jms-but-has-all-the-same-functionality-and-configuration.
In JSE, just make sure the schedulerthread runs on one node. All problems solved...
But that is my â‚¬0.014 (does anybody remember the time when it used to be â‚¬0.028?).
hmmm... I was sure I typed a € sign and not â‚¬ (has to be &#8364; because € does not work either, nor does & (had to use &#38; and do not even use preview)
I agree with Ronald. The feature sounds like Java EE, so why not using it...
though if there is a problem, it would be nice to know what the root cause is.
Sure, but some problems can be 'prevented' by just making sure they do not happen. Some do's and dont's for example around jee/jse use of jBPM functionality. We should not have to cope with all possible deployment.
E.g. the transaction issue reported by twicenightly ehh... twiceknightly is about using functionality as it was supposed to work but does not seam to.
Some do's and dont's for example around jee/jse use of jBPM functionality. We should not have to cope with all possible deployment.
i think that must be improved. and the new implementation of the environment should give us much more flexibility to resolve many of these inconvenience issues. on top of that, i would like to get more QA done on the most common combinations. that way we also should get more documentation of the various configurations. so people can start with an example configuration file that is exact or close to what they need
Tom, could you please look at JBPM-1072. There are my comments (from Alexey Kostylev). I think I've found a problem with optimistic locking - jobs are executed independently if locking was failed or not. Thank you.