jBPM's built-in asynchronous messaging

When using jBPM's built-in asynchronous messaging, job messages will be sent by persisting them to the database. This message persisting is done in the same transaction/JDBC connection as the jBPM process updates.

The job messages will be stored in the JBPM_JOB table.

The job executor (org.jbpm.job.executor.JobExecutor) will read the messages from the database table and execute them. So the typical transaction of the job executor looks like this: 1) read next job message 2) execute job 3) delete job message.

If execution of a job fails, the transaction will be rolled back. After that, a new transaction will be started that adds the exception stack trace to the job message in the database. The job executor filters out all messages that contain an exception.

Figure 13.3. Job executor transactions

Job executor transactions

If for some reason or another, the transaction that adds the exception to the job message would fail, it is rolled back as well. In that case, the message remains in the database without an exception so it will be retried later.

Limitation: beware that jBPM's built-in asynchronous messaging system does not support multinode locking. So you cannot just deploy the job executor multiple times and have them configured to use the same database.