This topic describes a typical application area of a Sync object. It shows how a Sync object controls access to a resource (in this example, a database).
Example 1: You want to control the access to the database
In this example you want to make sure that
- a maximum of 3 tasks can access the database simultaneously.
- exclusive database access by one task is also possible.
1. Create a Sync object with two states:
- EXCLUSIVE
- SHARE
It is important to give the states names that you can later on easily recognize.
2. Associate these states with the following values:
| State | Value |
|---|---|
| EXCLUSIVE |
0 - only one task can use the database |
| SHARE | 3 - up to 3 tasks can access the database simultaneously |
The value numbers are not explicitly written to the Sync object, they are integrated as soon as actions are defined (see below in this document).
3. Define the following 4 actions in the Action Definition section:
| State | Value |
|---|---|
| USE |
Normal (shared) database access. This action can be triggered if the Sync object is in SHARE status with a value below three. It keeps the current status, but the value increases by one. It is intended for normal tasks that access the database. The tasks check whether multiple database usage is possible; they also check if the value lies below three because only three tasks are allowed to access the database simultaneously. The value increases by one because one more task is now using the database. |
| USE_EXCLUSIVE | This action can be triggered when the Sync object is in SHARE status with value zero. This action is only possible if no other task uses the database. |
| RELEASE |
Release after normal (shared) access A normal task has used the database and is now terminating. The existing status remains but the value decreases by one. |
| RELEASE |
Release after exclusive access A task that has used the database exclusively now terminates and, in doing so, shared use of the database is possible again. |
The order in which you define the actions is relevant; the first one is the start status of the Sync object when applied to an executable object.
4. Assign the Sync object to an executable object
In our example, we assign the Sync object to a job. When processing this job, access to the database should be possible for other tasks, so we will choose the USE action:
How it works:
- The job starts and executes the USE action.
- It checks whether the database can currently be used multiple times (shared use) and counts the number of tasks using it. The job can only be started if fewer than three tasks are using the database.
- The action defined in "Else" is processed if the limit of 3 tasks has been reached. In this case, the job waits until one of these tasks has ended.
- As soon as that occurs, the waiting job starts, and either accesses the database successfully or aborts and the RELEASE action is processed.
Example 2: You want to synchronize the execution of two jobs in two different workflows
The order of tasks within a workflow is clearly defined by the lines linking them. But what about tasks which are part of different process plans and should still be executed interdependently?
There are two methods to solve this issue:
- External dependencies
- Sync objects
The first method is easily implemented and provides a clear structure and overview; it is therefore highly recommended. This example shows how to use the second one.
In our example, two workflows (WORKFLOW_A and WORKFLOW_B) include jobs (JOB_A1, JOB_A2 and JOB_B1, JOB_B2) that cannot run simultaneously. They must run one after the other each in its respective workflow, namely JOB_B2 must not start before JOB_A1 has ended.
1. Create the SYNC object
We create the EXAMPLE_STATE SYNC object, which maps the state of JOB_A1 and will contain two states:
- DONE, which means that processing is completed
- READY, which allows processing
Executable objects that have this object assigned can trigger its predefined actions. In our example, we will not use values. We define the following actions:
-
SET_READY
When the SYNC object has state DONE, this action is triggered. As a result of this action, the READY status is set.
Thus, this action can only be executed when a process has been completed.
-
SET_DONE
When the SYNC object has state READY, this action is triggered. As a result of this action, the DONEstatus is set.
Thus this action can only be executed when it is ready for processing.
2. Assign the SYNC object to JOB_A1
This job is part of WORKFLOW_A; it has no START action. When it ends, it triggers the SET_DONE action in the Sync object. As a result, the state DONE (end of processing) is set. A necessary precondition is that the current state is READY (for processing).
2. Assign the SYNC object to JOB_B2
This job is part of WORKFLOW_B2. It starts with the SET_READY of the Sync object. This action can only be carried out when the current status is DONE. This can only be the case when JOB_A1 has been completed. At the same time, this action sets the status READY (for processing).
3. Execute the workflows and watch the result
- WORKFLOW_A and WORKFLOW_B run parallel. Their status is ACTIVE.
- JOB_A2 is waiting for JOB_A1 to complete. This is the normal processing order of the workflow.
- JOB_A1 is running. Its status is ACTIVE.
- JOB_B2 is waiting for the state of the Sync object to change to DONE. As JOB_A1 is still running, the Sync object has the state READY. Only when JOB_A1 has ended will the Sync's state changes to DONE. This is when the job JOB_B2 starts.
See also: