The analysis thread hands off a copy of the route record. The analysis thread uses the EID to pull the event data from the database and the PID to get the current process state from the process data table. The event is analyzed based on the instructions in the process. When the analysis is finished the route record is updated to show that the event was analyzed, and the new process state is saved to the process data table. In addition to showing event flow, the picture also shows the points where data gets saved/updated on the database and the transaction boundaries. This shows the simplest case. In an actual running engine, there may be multiple capture/router threads and multiple analysis threads. In actuality, the flow may look really more like this:
As shown above, each analysis thread is responsible for a given set of process instances. If there is only one analysis thread, it will handle all instances running in the engine. If there is more than one analysis thread the engine uses an internal algorithm to determine which instance gets assigned to which analysis thread. Once an instance is assigned to a thread all its processing is done by that thread. These instances could all be the same process, just different instances, or they could be instances of different processes. The transaction boundary is per instance. Each analysis of PID6 by Analysis1 takes place within a transaction. Each analysis of PID8 takes place within another transaction. The analysis thread only works on one PID at a time. The others are in a "holding state". The analysis thread contains a list of all the routes for its PIDs, which is updated by the capture/route thread. It pulls the routes from the list one at a time -- first in, first out. It analyzes the PID in the route, using the data in the given event, and then pulls the next route from the list. New process instances are added to the analysis threads via the capture/route thread, as shown in the first flow graphic and completed instances are removed from the thread.