[jbpm-commits] JBoss JBPM SVN: r5414 - jbpm4/trunk/modules/devguide/src/main/docbook/en/modules.

[do-not-reply at jboss.org]

Author: alex.guizar at 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>