Issue refreshing object when multiple instances of the object are open in different sessions.

0
In our application, one object is open in two different sessions (it doesn't matter if these sessions belong to the same user or different users).  The object is open in a data view in both sessions, the data view shows the status of the object, in this case: 'error' In a microflow from one of the two sessions, the status of this object is changed to 'OK', and the object is commited and refreshed in client. Now, in only one of the two sessions the object is actually updated, stating 'OK'. in the other session, the object still shows 'error'.  Refreshing the object in the 'error' session doesn't help at all, the object really has to be completely reloaded in order to show the status update. I can kind of understand that when two people are working on the same object, if one commits and refreshes in client, the other doens't want to lose their changes. However, i also see this potentially corrupting data. In our case we want the object to be updated in both sessions at the same time, to prevent data from getting corrupt.   Does anybody have a workaround for this?
asked
2 answers
1

Try to implement a locking mechanisme that prevent two user from entering data for the same object at the same time.

There are some javaactions available in the community commons module to do this.

We implemented out own mechanisme that is not only used for locking separate objects but also for locking batches of object in case of transactionscoping of bulkupdates/creates.

answered
1

My assumption is that when one of the user changes something of this object the object gets committed to the database. Then you can do the following. In the community commons you have the action objectHasChanged. You could use the microflow timer widget https://appstore.home.mendix.com/link/app/27/Mendix/Microflow-Timer (note that at the moment there are two entires for this widget in the appstore, make sure you get the latest) to trigger a microflow that uses this Java action to check if a refresh is needed. You can then use another community commons action refreshClassByObject to force a refresh of the object.

Note that you still can run into troubles. Both could still change the object before the refresh check has taken place. I would recommend the locking mechanisme that Rene suggested. You could then let the other user open the object in read only modus. And with the method above the read version would still refresh when the other user changes the object.

Regards,

Ronald

 

answered