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.
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.