Users voice the requirement to have a log containing information about job execution.
The log should provide details about the complete lifecycle of a job:
- job created
- job execution failed (including retry information, exception message)
- job execution successful (including retry information)
- job was deleted
Created + (Failed)* + (Succeeded || Deleted)
Note that the information whether the job failed along with the exception message can only be logged at a best effort base.
The problem is that we only know whether a job failed after the transaction in which the job was executed is rolled back. There are no guarantees that we can actually log something at that point.
We will start with an implementation which sends a single event from a TX Synchronization (listener). If storing the event fails then we are OK with this.
In case of asynchronous continuations we cannot provide activity instance ids.
In that case we will provide:
- an activity id
- when we implement
CAM-3387, it will be visible before / after which historic activity instance a job execution happened.
other operations of jobs. Example: setRetries() would be logged in user operation log