Async Job Microflow Transaction Data not committed in between

Hello Mendix Guru’s,   We have the below use case: We have a Main Java Action that is executing Asynchronously in background Task Queue. It has 2 functional parts and correspondingly below 2 are separate Microflows. a) Fetch data from External system and persist in Mendix Database. Only after this is completed, we are going to below step (b) b) Trigger another Mircoflow which will retrieve the persisted data in (a) and perform some calculations on that newly persisted / Synced data from External system   What we have observed is that, even though we are fetching the data from External system and explicitly committing it in the Async Microflow in step(a) and then invoking the step (b) again asynchronously, the objects are at this point not yet committed / persisted in Mendix Database even though we have committed them in step (a) Microflow. This is happening because of Microflow Transaction as Mendix commits all objects only at the end of the Microflow Transaction.   We have even tried explicitly starting and ending transactions using the IContext context object in our Microflows by doing context.startTransaction() and context.endTransaction in java wherever required. But still the data is not committed.  As a workaround after ending the step (a) and performing context.endTransaction() we added Thread.sleep(2000) with 2 seconds. and now the objects are getting committed. But we want to avoid Thread.sleep and ensure the objects are committed after step(a) so it can be fetched by step(b) for further usage for calculation.   We have tried different mechanisms like creating new context for step (a) and step (b) and various other things which we could find in the forums, but none of them are working except Thread.sleep along with starting and ending transactions.   Kindly let me know if you require more information to analyze this issue and I shall provide the same. Thanks & Regards, Aniketh
1 answers

Would it be possible to execute b in the task queue? If so, a could execute b in task queue when a is done and when b starts, the transaction from a is already finished.