Is it Safe to delete rows on AUTOCOMMITENTRY table?

0
Hello, We recently experiencing deleted rows behaviour on production while there is no explicite DELETE on the application level. After search, we come across some insghits that blames “autocommit” feature for that bahaviour. Then, we checked (autocommitentry table and logs) we noticed that there is many rows there that should not be committed.  My question : is it safe to delete those entries to prevent any futher commits of the data?   Best regards.  
asked
2 answers
2

Deleting auto committed rows can be done, but delete them through the mendix runtime (clean up microflow) to ensure associations are deleted as well. Don't delete them straight from the database using a DB tool

 

Things to consider

  1. Check where and why they are auto committed. Autocommits are result of a commit of a object which is referencing a not yet committed object. Which forces a Autocommit on the referenced object.
  2. Always commit the parent object first before committing child object. Ie commit order object before borderline objects.
  3. Always be in charge of your commits. Don't take commit behaviour of Mendix for granted

Hope this helps

 

 

answered
1

Hi EL OUAFI Omar,

 

I think you can safely delete Autocommitentry table. Autocommitentry table seems to only keep inserted records and they are inserted to this table right after the auto commit happens.

See the below trace and you can see the Main object was auto committed before an Autocommitentry record inserted. In this testing, I committed the the Child object and ignored the Main object.

 

EntityStorer: Incoming StoreRequest: ObjectStoreRequest type: CREATE, size: 1 object(s) Object types: [MyFirstModule.Child]
SQL@5acb7d55(T63-C2a4b7a2b): INSERT INTO "myfirstmodule$child" ("id", "name", "age") VALUES (?, ?, ?)
SQL@2c32b60d(T63-C2a4b7a2b): DELETE FROM "myfirstmodule$child_main"  WHERE "myfirstmodule$childid" = ?
SQL@5d591b82(T63-C2a4b7a2b): INSERT INTO "myfirstmodule$child_main" ("myfirstmodule$childid", "myfirstmodule$mainid") VALUES (?, ?)
EntityStorer: Incoming StoreRequest: ObjectStoreRequest type: CREATE, size: 1 object(s) Object types: [MyFirstModule.Main]
SQL@5c79e4a9(T63-C2a4b7a2b): INSERT INTO "myfirstmodule$main" ("id", "name", "date", "number") VALUES (?, ?, ?, ?)
EntityStorer: Incoming StoreRequest: ObjectStoreRequest type: CREATE, size: 1 object(s) Object types: [System.AutoCommitEntry]
SQL@1d41f4bf(T63-C2a4b7a2b): INSERT INTO "system$autocommitentry" ("id", "sessionid", "objectid", "createddate") VALUES (?, ?, ?, ?)

 

The cascading delete behaviors are ruled by the association properties page. Therefore, I believe there is no auto commit for deletion but I may be wrong.

 

 

Can you share your experience how you discovered unexpected deletions came from autocommitentry?

 

Thanks,

Huy

answered