Date: Fri, 29 Mar 2024 06:25:40 +0100 (CET) Message-ID: <1188573958.3617.1711689940787@263d865a522e> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_3616_392218660.1711689940786" ------=_Part_3616_392218660.1711689940786 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
In models with high throughput, it can be helpful to split a task into m=
ultiple independent actions. To do that, use Persistent States to create Persistent=
State objects or model a state machine with fork and join.
Modeling Persistent States is easier than managing individual threads. Also=
, support for tracing, debugging and managing is offered for Persistent Sta=
te.
With the deprecated Thread Adapter you can create threa= ds from a service call (main thread) or independent threads. Each new threa= d runs an operation parallel to the main thread. Threads do not share any d= ata. Input data to the operation is cloned before a new thread starts. The = session handling (commit and rollback) is separated. A thread has no output= parameters besides the automatically generated threadID (= see Thread Adapter Reference). Threa= ds can be created with any amount of input parameters but the called operat= ion will not provide any output parameters.
In the main thread, you can wait for other threads to complete by using = the <<WaitForThread>> action. If you don't wait, the other threads will run in the background.=
With the Thread Adapter, you can