Author: alex.guizar(a)jboss.com
Date: 2009-07-31 18:09:42 -0400 (Fri, 31 Jul 2009)
New Revision: 5414
Modified:
jbpm4/trunk/modules/devguide/src/main/docbook/en/modules/ch11-JobExecutor.xml
Log:
[JBPM-2402] verify job executor threads in case of errors
update devguide text to changes in codebase
Modified: jbpm4/trunk/modules/devguide/src/main/docbook/en/modules/ch11-JobExecutor.xml
===================================================================
---
jbpm4/trunk/modules/devguide/src/main/docbook/en/modules/ch11-JobExecutor.xml 2009-07-31
15:29:15 UTC (rev 5413)
+++
jbpm4/trunk/modules/devguide/src/main/docbook/en/modules/ch11-JobExecutor.xml 2009-07-31
22:09:42 UTC (rev 5414)
@@ -4,7 +4,7 @@
<para>
For jPDL features like asynchronous continuations and timers, jBPM
- relies on transactional asynchronous messaging and transactional
+ relies on transactional asynchronous messaging and
timers. Those are not available on the standard Java platform.
Therefore, jBPM includes the JobExecutor component, which executes
asynchronous messages and timers in any (potentially clustered)
@@ -51,12 +51,12 @@
<listitem>
A <emphasis role="bold">shared BlockingQueue</emphasis>,
which is used to temporary store job identifiers of jobs which
- are executable (eg duedate is passed).
+ are executable (e.g. due date is passed).
</listitem>
<listitem>
Every JobExecutor has one <emphasis
role="bold">DispatcherThread.</emphasis>
- This thread will query the database for 'acquirable jobs' (eg timers
- which duedate is passed), using a dedicated command through the CommandService.
+ This thread will query the database for 'acquirable jobs' (e.g. timers
+ which due date is passed), using a dedicated command through the CommandService.
Since the dispatcher uses the CommandService, the command is
automatically made transactional and wrapped by the configured
interceptors. As long as jobs are available the dispatcher will put
@@ -65,24 +65,21 @@
free) or until no new jobs can be found in the database. If the latter
case, the dispatcher will wait for a configured time (ie the 'idle
time').
- </listitem>
+ </listitem>
<listitem>
- The JobExecutor also maintains a pool of
- <emphasis role="bold">JobExecutorThreads</emphasis>. The number
of
- JobExecutorThreads can be configured and influences the size of the
- shared queue. Every one of the JobExecutorThreads will try to take a
- jobId from the queue. The shared queue implementation is guaranteed to
- block the JobexecutorThread until a queue slot is filled and the new
- job id will be passed to exactly one waiting JobexecutorThread.
- After taking a job id from the queue, the job is transactionally
- executed using a dedicated command through the CommandService. This
- means that the job logic will completely be executed on the
- JobExecutorThread, instead of the default calling thread. This also
- means that the order in which the jobs are executed is unknown since
- there could be multiple competing JobExecutorThreads, but it
- is certain that only one job per transaction will be done (unless using
- 'exclusive jobs' - in this case all exclusive jobs are sequentially
- executed).
+ The JobExecutor also maintains a pool of job executor threads. The number of
+ executor threads can be configured and influences the size of the shared
+ queue used to transfer and hold submitted jobs. Each executor thread will take a
+ job from the queue. The shared queue blocks the executor threads until a job
+ is queued. The new job will be acquired by exactly one waiting executor thread.
+ After taking a job from the queue, the job is transactionally
+ executed using a dedicated command through the CommandService. Therefore,
+ the job will be executed completely on the executor thread
+ instead of the caller thread. In consequence, the order in which the jobs
+ are executed is unknown since there are multiple competing executor threads.
+ However, it is certain that only one job will be done per transaction,
+ except for <emphasis>exclusive</emphasis> jobs. In this case,
+ all exclusive jobs are sequentially executed.
</listitem>
</itemizedlist>
</para>
Show replies by date