Core.commitWithoutEvents does not commit in database ?!

0
Hi ! I created Java actions to batch load data (retrieved from SAS Datasets) in Entities. In the Java: ResultSet resultSet = statement.executeQuery(queryText); List<IMendixObject> claimHFList = new ArrayList<IMendixObject>(); while (resultSet.next()) { lineNumber++; ClaimHF claimHF = new ClaimHF(context); // assign data in claimHF claimHFList.add(claimHF.getMendixObject()); if (lineNumber % batchSize == 0) { List<IMendixObject> committedObjects = Core.commitWithoutEvents(context, claimHFList); claimHFList = new ArrayList<IMendixObject>(); logger.debug("Committed ClaimHF at line " + lineNumber + " (" + committedObjects.size() + " objects committed)"); } } List<IMendixObject> committedObjects = Core.commitWithoutEvents(context, claimHFList); logger.debug("Committed ClaimHF at line " + lineNumber + " (" + committedObjects.size() + " objects committed)"); BUT the Core.commitWithoutEvents does not commit the data into the database. It seems that the data are really committed on exit of the microflow that calls the Java action. The problem is that we have one microflow that calls 15 Java actions, loding millions of objects into Entities. When we execute that microflow, everything seems to execute successfully (no exception, no error message) but most of the tables are empty, only the last loaded entities contains data. So, it seems that the data loaded in the first Java actions are lost. My questions : How can one explain that the data loaded and committed in the first loaded entities are lost ? How to make sure that the Core.commitWithoutEvents does a real database commit ? When does the real database commit occur ? How to trigger it from a Java action ? Thanks in advance for your help. Philippe
asked
4 answers
1

commitWithoutEvents(), just like commit() does an update or insert in the database (yes the naming is poor), at the end of the transaction it is actually committed. However, it looks like this should simply be happening in your case. You don't seem to be doing anything manually in terms of transaction starting/ending. But you will have to wait until everything is finished until you can see the data from within a DIFFERENT transaction. This all does not explain your issue yet though.

answered
0

I also tried to call the Java Action from a SUB microflow (hoping that the database commit would occur when exiting the SUB microflow)... but no luck... It doesn't help.

answered
0

To accomplish what you need, you would can call this microflow asynchronously, and then await its completion.

You can most easily do this by employing the RunMicroflowAsync Java action that's in the CommunityCommons library.

You can also do this your self using the Mendix API. Off the top of my head it's something like Core.executeAsync.

answered
0

Philippe, your post is not entirely clear on how you are observing the behaviour you describe and why you would need an immediate commit.

If you are doing something like querying the database while the microflow is still running what you see happening is what you would expect.

If however, the data is not in the database after the entire microflow has finished, then you have likely run into a Mendix bug.

Normally you would not have any need for your seperate Java actions to commit to the database (I am using the real meaning of commit here, not the Mendix meaning), as they should all be running in the same database transaction so would see each other's data when querying the database.

I can't think of a good way how you could check that all you Java actions are indeed running in the same transaction, a way that will surely work is to enable trace logging for all database actions including transaction management in your database.

answered