Scenario 1) Polling BPEL process
With AIA service constructor, following composite XML structure is already created
If process is polling process and it has following transaction properties:
<property name="bpel.config.transaction">required</property>
<property name="bpel.config.oneWayDeliveryPolicy">sync</property>
It puts process in transaction and if there is any error during processing, transaction will roll back. But with polling process transaction roll back will cause message to to go back in the source (file/jms, etc), and therefore a new instance of BPEL process will get created. This behavior will cause infinite loop scenario.
The simple resolution is to just remove these properties but in case we need transaction to work, we need to make sure that appropriate error handling is done.
Scenario 2)
Regardless of process is synchronous or asynchronous, AIA error handling fault policy is always integrated for AIA process. We had configured AIA fault policy to go human intervention after CompositeJavaAction was executed. Synchronous process needs to be completed transaction timeout but if there is any error, due to fault policy it will end up in Running state.
We saw that every time we restart the server, it somehow wakes up the running instance, and invokes AIA error handling again.
I guess for this particular scenario, it was the Fault Policy in Sync process causing the issue, but we have seen many other scenarios were instance can get stuck in Running state.
