Bug 780166 (SOA-2542)

At present we copy the enterprise behaviour in jBPM, for example the following

    if (job.isExclusive()) {
        jbpmContext.getGraphSession().lockProcessInstance(processInstance);
    }

I'm assuming from your report that this does not work properly so can you please provide a working test case and logs?

The linked support case is not visible to me.

Lock Upgrade puts a database lock, which makes other threads wait for the lock to be removed before continuing until a timeout or the lock is removed.

Also, once it does unlock, every live thread dealing with the same process ID gets a StaleObjectException.  So they restart, each locking the db and gumming things up. 

If you make this simple change, then you shouldn't encounter these problems.

I can create a process which demonstrates this.  

I will work on that and attach it.

Sounds like it should be straight forward for you to provide me with an example in that case.  I will decide on the 'simple' change once I have seen what is happening.

I should also add that the exclusivity only applies to Jobs in the jBPM codebase, not timers nor commands.

Kevin, attached is the example.  To run it, deploy the process and then through the jbpm console start and signal the initial token.

Process with failure of timers, AKA Jobs.

Attachment: Added: sample-jbpm-1.0.0.par

Also, I have tried this with the HSQL and Postgres databases behind jBPM.  

Attached is the log requested.  As you can see, with jBPM and Postgres, timers and async="exclusive" for the Join, you still get issues with the StaleObjectExceptions.

Attachment: Added: server.log

Fantastic, thanks very much for that.

Please note that timer execution is *not* the same as job execution in the current codebase, only jobs are protected by exclusivity as I mentioned earlier. Timers are *not* AKA jobs.

If my gut instinct is correct then there may be a couple of areas that need tidying up.

The approach I used at a client which worked very well was to add:

message.setStringProperty("JMSXGroupID","jBPMPID:"+job.getProcessInstance().getId());

to the Messaging Service, when the Job was to execute exclusively.  This allows the JMS system to only deliver to one consumer.  The benefit of this is that it does not lock the DB, which can really gum up systems if you have a large number of exclusive jobs. 

About Timers vs Jobs, either way is fine with me.  I thought I saw in your codebase that the JobListener picks up Timers and then creates a Command object.  I guess I assumed you had Timers going to the Job queue.

EItherway, the approach I am using should not be used with Timers.  Only Jobs.  The reason is that JBoss Messaging recommends you *not* set both the scheduled delivery property and the group ID.  

It does create commands, but a different one for each.  It is the command that does the locking.

The approach you have chosen does affect both timers and jobs but is not recommended, as you have found.  I also suspect another area needs changing, but will chase this up when I look at it in detail.

Kevin, the approach I took does not affect timers.  I only add that property when it is not a timer.  The source for that is:

if(!(job instanceof Timer) && job.isExclusive())
{
    		message.setStringProperty(JMS_PROP_GROUP, JBPM_GROUP_PREFIX+job.getProcessInstance().getId());
}

Not a candidate for SOA 5.1.0

Link: Added: This issue Cloned to JBPM-3424

Given the following: 

1. https://access.redhat.com/support/cases/00371420 mentions that "this is more of a feature request than an outright bug or breakdown"
2. jBPM 3 is in maintenance mode for SOA 5, and slowly but surely nearing EOL. 
3. We should _not_ be encouraging any dependence on jBPM 3 and should be encouraging migration to jBPM 5. 

Given above, I'm closing this bug. The only issues that should be fixed at this point for jbpm 3 are bugs that break things for clients. 

If I'm incorrect on this, please reopen the issue.