Conversation
| When you commit an object, all changes to the current values are saved. This means that you cannot roll back to the previous values of the object using the **Rollback object** activity of a microflow. | ||
|
|
||
| However, a Mendix commit is not the same as a database commit. For an object of a persistable entity, the saved value is not committed to the database until the microflow and any microflows from which it is called, complete. This means that errors in a microflow can initiate a rollback. If a microflow activity errors and has **Error handling** set to **Rollback** or **Custom with rollback**, the value of the object is rolled back to the value it had at the start of the microflow. See [Error Handling in Microflows](/refguide/error-handling-in-microflows/) for more information. | ||
| However, a Mendix commit is not the same as a database (SQL) COMMIT. When you use a **Commit object(s)** activity, Mendix actually performs an INSERT into the database. For an object of a persistable entity, the saved value is not committed to the database until the microflow and any microflows from which it is called, complete. This means that, although the current end user can see the updated version of the object, other end users will not see the updated object until the microflows end. |
There was a problem hiding this comment.
Only if the object is new, does a commit action perform a database INSERT. Otherwise, it performs a database UPDATE.
| When you commit an object, all changes to the current values are saved. This means that you cannot roll back to the previous values of the object using the **Rollback object** activity of a microflow. | ||
|
|
||
| However, a Mendix commit is not the same as a database commit. For an object of a persistable entity, the saved value is not committed to the database until the microflow and any microflows from which it is called, complete. This means that errors in a microflow can initiate a rollback. If a microflow activity errors and has **Error handling** set to **Rollback** or **Custom with rollback**, the value of the object is rolled back to the value it had at the start of the microflow. See [Error Handling in Microflows](/refguide/error-handling-in-microflows/) for more information. | ||
| However, a Mendix commit is not the same as a database (SQL) COMMIT. When you use a **Commit object(s)** activity, Mendix actually performs an INSERT into the database. For an object of a persistable entity, the saved value is not committed to the database until the microflow and any microflows from which it is called, complete. This means that, although the current end user can see the updated version of the object, other end users will not see the updated object until the microflows end. |
There was a problem hiding this comment.
"the saved value is not committed" it still confusing, as it is not clear what type of commit this refers to. After the commit action, the object is in the database, but the transaction has not yet been committed. The effect is that any retrieve from database in that same transaction/microflow will see the (new state of) the object, but other transactions (including, but not limited to, other users) will not see the change. When the microflow ends, the transaction is committed and the change becomes visible globally.
| | --- | --- | | ||
| | Rollback (default) | All changes are reverted to the state before the microflow started, the microflow aborts, and a system error message is shown. | | ||
| | Custom with rollback | All changes are reverted to the state before the microflow started, an error flow is followed, and the microflow's subsequent behavior depends on whether the error handling flow ends with an error or end event. | | ||
| | Custom without rollback | Changes made before the error are kept, an error flow is followed, and the microflow's subsequent behavior depends on whether the error handling flow ends with an error or end event. | |
There was a problem hiding this comment.
It may be more accurate to say that "Changes made before the activity causing the error are kept". If you commit a list of objects and the third one fails, the changes for the first two objects will be rolled back before the error flow starts.
| | Rollback (default) | All changes are reverted to the state before the microflow started, the microflow aborts, and a system error message is shown. | | ||
| | Custom with rollback | All changes are reverted to the state before the microflow started, an error flow is followed, and the microflow's subsequent behavior depends on whether the error handling flow ends with an error or end event. | | ||
| | Custom without rollback | Changes made before the error are kept, an error flow is followed, and the microflow's subsequent behavior depends on whether the error handling flow ends with an error or end event. | | ||
| | Continue | The microflow proceeds as if no error occurred, keeping all changes, and no error message is logged or displayed to the end-user. | |
There was a problem hiding this comment.
Similarly, it keeps all changes from before the activity causing the error.
|
|
||
| ### Consistent Data | ||
|
|
||
| Everything that happens in your app happens in a transaction. By default either all instructions are completed or nothing is completed. If you don't specify any error handling and the microflow you are trying to run encounters an error, it will appear that nothing has changed. That means that all the objects you created or changed will be reverted, and the end-user will get an error. This ensures that processes and data remain consistent. |
There was a problem hiding this comment.
We don't tend to use "instructions", maybe "activities"? But this only applies to local objects, any calls to external systems cannot be reverted by a transaction rollback.
|
|
||
| ### Protection from Parallel Updates | ||
|
|
||
| When an object is updated, your app will place a lock on that object until the transaction/microflow ends. While the microflow is running, nothing else can read or write that same object and anything that attempts to do so will have to wait. This lock is released automatically as soon as the microflow ends, allowing any waiting processes to continue normally. |
There was a problem hiding this comment.
You can read an object that was updated and therefore locked by another transaction. Locks do not block reads, only other writes. The value you will see will not include any changes by uncommitted transactions.
2 participants
No description provided.