Detailed Description: node synchronization function in FORK of Java EE Workflow Management System jBPM

BKJIA has been paying attention to the Java EE Workflow Management System jBPM. In the Java EE Workflow Management System jBPM, apart from the function nodes that refer to START-STATE, END-State, Fork, Join, demo, the business logic is implemented in the ACTION of the NODE. This article describes the node synchronization function in the FORK of Java EE Workflow Management System jBPM.

 
 

  
  
Public class DemoActionHandler implements ActionHandler {
  
  
 
  
  
Java code
  
  
/**
  
  
* Simple ACTIONHANDLER DEMO
  
  
*/
  
  
Private static final long serialVersionUID = 1L;
  
  

  
  
@ SuppressWarnings ("unchecked ")
  
  
@ Override
  
  
Public void execute (ExecutionContext executionContext) throws Exception {
  
  
Node node = executionContext. getNode ();
  
  

  
  
System. out. print (executionContext. getProcessInstance (). getId ());
  
  
System. out. println ("-- [" + node. getName () + "] ["
  
  
+ New java. util. Date () + "]");
  
  
ContextInstance cxtInstance = executionContext. getProcessInstance ()
  
  
. GetContextInstance ();
  
  
Try {
  
  
Date date = new Date ();
  
  
Date startDate = (Date) cxtInstance. getVariable ("STARTDATE ");
  
  
System. out. println ("total execution time on this node:" + ""
  
  
+ (Date. getTime ()-startDate. getTime ()));
  
  

  
  
} Catch (Exception e ){
  
  
E. printStackTrace ();
  
  
}
  
  
Thread. sleep (6000 );
  
  
Node. leave (executionContext );
  
  
}
  
  
}
  
  
 
 
 

I wrote a simple process, serial, and does not contain branches. It only contains three types of nodes: Start, end, and NODE. Release the process, create an instance, and query and track the location of the token in polling mode after the instance is started (if there is a branch, you may need to consider the situation of sub-token ), the monitoring results of a process are found to have only two nodes: START and END. Why? First of all, the status of the process instance is not saved in real time or persisted to the database.

Then I thought about it in combination with my own program. All nodes in the program are NODE-Type Automatic nodes. During the process execution, the process instance will not be persistent to the database until a NODE is waiting. But if the async asynchronous execution of the NODE is set to true, the process will start a thread to execute the node actionhandler when it is executed to the NODE, and the TOKEN itself will be suspended, the transaction is also split into two independent transactions. that is to say, a transaction from the beginning to the waiting state is divided into multiple transactions by the asynchronous node. The process will commit the transaction when executing the ACTIONHANDLER of the asynchronous node, the status of the Process instance will be persisted to the database.
Add

 
 

  
  
Java code
  
  
Node. setAsync (true );
  
  
 
 
 

Then we tested the branch and found that the nodes under fork were executed in sequence. We checked the information and said the following:

Reference

The underlying layer of fork is actually to call each transition in sequence, rather than the actual synchronization. If you need to synchronize, refer to JBPM asynchronous settings.

Therefore, the async attribute of the FORK node is set to true. After the test, it is still unavailable. According to the preceding statement, fork uses a Traversal method to call each branch when executing each branch, but does not have to execute one branch before executing another branch. I had no choice but to put it down and began searching for information. This part of work was stranded for nearly a day. When I checked the information at home in the evening, I found someone mentioned the number of JobExecutor threads. I think this may be the reason. Go through the source code and find an API to test it.

 
 

  
  
Java code
  
  
JobExecutor = jbpmConfiguration. getJobExecutor ();
  
  
JobExecutor. setNbrOfThreads (5 );
  
  
JobExecutor. start ();
  
  
 
 
 

The result is a comedy. I was pleasantly surprised to find that the nodes under fork have been executed synchronously. Of course, there will also be a sequence of synchronous execution ).

Although this is the basic function of fork nodes, there will still be various trophy issues in actual use. The reason is that, if the number of threads is not set, JobExecutor starts a thread to work by default, which causes the nodes under fork to enter the queue and the result is serial execution.