svn commit: r1738907 - /sling/site/trunk/content/documentation/bundles/apache-sling-eventing-and-job-handling.mdtext

[cz...@apache.org]

Author: cziegeler
Date: Wed Apr 13 08:06:43 2016
New Revision: 1738907

URL: http://svn.apache.org/viewvc?rev=1738907&view=rev
Log:
Clarify job processing

Modified:
    sling/site/trunk/content/documentation/bundles/apache-sling-eventing-and-job-handling.mdtext

Modified: sling/site/trunk/content/documentation/bundles/apache-sling-eventing-and-job-handling.mdtext
URL: http://svn.apache.org/viewvc/sling/site/trunk/content/documentation/bundles/apache-sling-eventing-and-job-handling.mdtext?rev=1738907&r1=1738906&r2=1738907&view=diff
==============================================================================
--- sling/site/trunk/content/documentation/bundles/apache-sling-eventing-and-job-handling.mdtext (original)
+++ sling/site/trunk/content/documentation/bundles/apache-sling-eventing-and-job-handling.mdtext Wed Apr 13 08:06:43 2016
@@ -22,7 +22,12 @@ In general, the eventing mechanism (OSGi
 
 On the other hand, there are use cases where the guarantee of processing is a must and usually this comes with the requirement of processing exactly once. Typical examples are sending notification emails (or sms), post processing of content (like thumbnail generation of images or documents), workflow steps etc.
 
-The Sling Event Support adds the notion of a job. A job is a special event that has to be processed exactly once. To be precise, the processing guarantee is at most once. However, the time window for a single job where exactly once is very small and only happens if the instance which processes a job crashes after the job processing is finished but before this state is persisted. Therefore a job consumer should be prepared to process a job more than once.
+The Sling Event Support adds the notion of a job. A job is a special event that has to be processed exactly once. 
+To be precise, the processing guarantee is at most once. However, the time window for a single job where exactly 
+once can't be guaranteed is very small. It happens if the instance which processes a job crashes after the job 
+processing is finished but before this state is persisted. Therefore a job consumer should be prepared to process
+a job more than once. Of course, if there is no job consumer for a job, the job is never processed. However this
+is considered a deployment error.
 
 The Sling Jobs Processing adds some overhead, so in some cases it might be better to use just the [Commons Scheduler Service]({{ refs.scheduler-service-commons-scheduler.path }}) or the [Commons Thread Pool]({{ refs.apache-sling-commons-thread-pool.path }}) for asynchronous execution of code.