Bulk processing via SQS → Java Action → Microflow: data not persisted, suspect rollback (no errors in logs)

0
Context I have a background flow that processes bulk data: Trigger: SQS message Entry point: Mendix Java Action (reads SQS, then calls a microflow) Processing: The microflow parses JSON and creates/updates entities Transaction control: Using CommunityCommons StartTransaction / EndTransaction in a sub-microflow Symptom: The flow completes “gracefully” (last activity logs), but no data is persisted in Mendix DB. I don’t see any ERROR/EXCEPTION lines for this run. The last log line indicates the final activity executes as expected, so I suspect a rollback is happening somewhere, but it’s not obvious from the logs.   Questions Transaction semantics with Start/EndTransaction inside a sub-microflow If I open a transaction with StartTransaction and close it with EndTransaction inside a sub-microflow, what happens if an unhandled exception occurs later in the caller (outer) microflow? Does Mendix roll back only the inner transaction, or can the entire (outer) action rollback, effectively undoing the inner commit? Detecting rollbacks from logs Which log nodes and levels should I enable to reliably see BEGIN TRANSACTION / COMMIT / ROLLBACK boundaries? Is there a canonical way in Mendix logs to identify implicit rollbacks (e.g., due to entity events or exceptions caught/handled upstream)?   What I’ve tried / Observations The flow uses CommunityCommons StartTransaction and EndTransaction around the DB work. The final activity in the flow logs as executed; no visible errors or stack traces. No errors under common nodes like Core, Connector, ActionManager, ConnectionBus_Retrieve/Update/Mapping at default levels. Objects are explicitly Committed in the microflow (not just kept in memory).   What guidance I’m looking for Clarification on nested transaction behavior (inner StartTransaction/EndTransaction vs. outer microflow/thread). The definitive log nodes/levels to turn on to see transaction boundaries and rollbacks (e.g., ConnectionBus at TRACE, Database at TRACE, Core at DEBUG, ActionManager at TRACE — please confirm best practice). Any gotchas that can cause silent rollbacks in background processing: Before/After Commit event microflows throwing/returning errors. Commits with events enabled vs without events from Java actions or microflows. Error handlers that catch exceptions (hiding ERROR logs) but still cause the runtime to abort/rollback the transaction.  
asked
1 answers
0

Its not totally clear what you are doing.

Are you explicitly handling transactions in MF with Start and end transactions? If Yes, why do you want to do, for the scenario, you explained above.

You pass the JSON from Java action to MF and probably using import mapping to convert the JSON to objects of specific entity. But, when doing the import mapping, are you committing the processed objects automatically within the import mapping? OR atleast commit them outside after some post processing.

https://docs.mendix.com/refguide9/import-mapping-action/#commit

 

If there is an exception, I suspect, that could possibly happen within the Java action that calls the MF or if there are other java actions within the MF to process data, it is easy to handle them yourself and log them with some custom log node.

 

If you dont log anything and leave it for default behavior, then obviously there will be a rollback, in which case, you should be looking at the application logs to know more about error happened. Because there will be stack trace for sure.

 

Mendix handles the transactions by itself for every MF. Its better to not intervene unless we know what we are doing and only if its required.

answered