This content has been marked as final. Show 9 replies
Verify that the asynch process delivery property is set to asynch.persist and the synch process transaction property is set to requireNew.
Awesome it worked . I just changed the transaction to requiresNew in the calling synchronous bpel service and it worked. I spent an entire day on thsi .
If you could throw some light on what the problem could have been it would be a good learning
Thanks a lot
I would like to hear from you on what difference this requriesNew has made. I understnad that it makes the sync process to excecute in a new transaction. but since this is the one that starts and invokes the async process it always starts in a new transaction.
Please help me understand
I read the explanation in that thread but still not clear on the behavior. Sync by default is required and when it invokes a async target why the asnyc target is not able to call back the synchronous process.
When you run a synch process it is not recommend to call a an asynch process.1 person found this helpful
If you do that, you are changing the behavior of your process.
So, if you've decided to call an asynch' process, your main synch' process "need" to understand that it is "acting" now as an asynch' process.
For that you should use the requiresNew and not required. With requiresNew, the transaction manager knows who is the real caller, and to whom the message should come back to.
Hope that was a better explanation.
that was helpful, i googled to find few links that would give a detailed understanding but not convincing.
1. Sync Process with requiresNew starts in a new transaction .
2. Invoke Async (async.persist, which causes to execute in a new transaction/thread) , the current sync thread/transaction is suspended on its receive activity and the new async thread starts
3.When the async process is done, the call back(basically a invoke activity) invokes the caller
What if sync process config is set to requires, since there is no transaction the BPEL service engine always starts a new transaction right?
why does the Tx manager not sure whom to reply when the caller transaction (sync process) is set to requires.
I have been googling all day to understand this concept better
a small configuration change fixed my issue. I would like to know how is that configuration change fixed thsi issue