Shulou(Shulou.com)06/02 Report--

This article is about how to understand the Java EE workflow management system jBPM FORK node synchronization function, the editor thinks it is very practical, so share it with you to learn, I hope you can get something after reading this article, say no more, follow the editor to have a look.

In the Java EE workflow management system jBPM, except for the function node (START-STATE,END-State,Fork,Join,Decision), all the business logic is implemented in the ACTION of the NODE node. The editor will explain in detail the node synchronization function in 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 ("when sharing to this node:" + "+ (date.getTime ()-startDate.getTime ();} catch (Exception e) {e.printStackTrace ();} Thread.sleep (6000) Node.leave (executionContext);}}

I wrote a simple process, serial, no branches, only start, end, NODE three types of nodes. Publish the process, create an instance, query and track the location of the token by polling after the instance is launched (if there is a branch, you may need to consider the sub-token), and find that the monitoring result of a process has only two nodes: START and END. Why? the first thing that comes to mind is that the state of the process instance is not saved or persisted to the database in real time.

Combined with my own program, all the nodes in the program are automatic nodes of NODE type, and when the process is executed, the process instance will not be persisted to the database until a waiting node. However, if the true is set to the async (asynchronous execution) property of the NODE node, the process will start a thread to execute the ACTIONHANDLER of the NODE when it is executed to that node, and the TOKEN itself will hang and wait for the message that the execution is complete, so the transaction will be split into two separate transactions. In other words, a transaction from the start to the waiting state is divided into multiple transactions by the asynchronous node, and the process commits the transaction when executing the ACTIONHANDLER of the asynchronous node, and the state of the process instance is persisted to the database.

So add

Java Code node.setAsync (true)

Then, when there are branches in the test, it is found that the nodes under the fork are executed sequentially. After checking the data, there is the following statement.

Quote

The bottom layer of fork is to call each transition in turn instead of synchronization. If synchronization is needed, please refer to JBPM async configuration.

So the async property of the FORK node is also set to true, and it is found that it still doesn't work after testing. According to the above, when fork executes each branch, it invokes each branch in a similar way, but it does not have to execute one branch and then another. I had no choice but to put it down and began to look for information, and this part of the work was therefore stranded for nearly a day. When I was looking up the data at home in the evening, I found that someone mentioned the number of threads in JobExecutor. I think it's possible that this is the reason. Look at the source code and find an API to try it out.

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

As a result, it was a comedy, and I was pleasantly surprised to find that the nodes under the fork were executed synchronously (of course, there will be a sequence of synchronous execution).

Although this is the basic function of the fork node, it still encounters all kinds of booty-like problems when it is actually used. 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.

The above is how to understand the FORK node synchronization function of Java EE workflow management system jBPM. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.