Talk about the transaction problem of serviceTask when activiti workflow is integrated with spring

Everyone should know the main role of serviceTask, so I won't go into details here, but talk about the problems encountered.

At first, I have been using the activiti:expression attribute of serviceTask to directly refer to a method of serviceBean for invocation. There is no problem. However, this service method needs to do database operations, so it will involve spring transactions, and transactions will be submitted. , there will also be a rollback. Naturally, I think of throwing exceptions to do transaction rollbacks, and Activiti's exception boundary event also needs to throw a runtime exception BpmnError, so I take it for granted to throw BpmnError in this serviceBean The final result is that spring rolled back the transaction, but the activiti job failed to flow normally. After detailed research, it was found that the transaction that should be activiti was also affected by the spring transaction rollback, so I decided to isolate activiti from spring. Come, the specific way is to use the activiti:delegateExpression of serviceBean, write the delegate separately, register the delegate with @Component, and then use the delegate to call the service. Since the transaction of the service cannot be affected by the delegate, it is called by the component. Add the annotation @Transactional(propagation = Propagation.REQUIRES_NEW) to the service method, the test is OK, when the service throws a RuntimeException, the spring bean transaction is rolled back, then the exception is caught in the component, and a BpmnError is thrown, activit's serviceTask Exception boundary events registered in .

 

In addition, it should be noted that if the activiti:async attribute of serviceTask is true, the exception boundary event will not take effect.

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326593618&siteId=291194637