I've just spent some time trying to find a solution to an interesting problem a colleague of mine had (See this post: https://forum.mendixcloud.com/link/questions/87166).
In summary; we want to trigger a refresh of an object in the client of user A1 based of an action in the client of user A2. A microflow-timer or some similar polling mechanism is out of the question, as this interferes with the session-timeout after 10 minutes of inactivity (a requirement from a security standpoint).
Normally you'd probably resolve this using websockets (or a similar setup), but alas, Mendix gives us very limited control in this regard.
However, I figured I might have a workaround. We tried the following:
1) Create a 'notificationCounter' object that we want to refresh, and associate it to user-session for each logged-in user
2) Create a simple java-action that retrieves all active user-sessions, and for each session retrieves the associated notificationCounter object
3) Update and refresh all notificationCounter objects
My hope was that as we retrieved the specific in-memory instance of the notificationCounter for each user-session, the refresh would cause Mendix to send the refresh order to the correct client.
I gave it high odds this wouldn't work (though it was worth a try), and indeed it did not. We did get the correct notificationCounter object for the user-sessions (GUID as the same), but not only did the refresh have no effect in the other client, the change we made to the object (changed the count) was also not applied to the instance of object in the other user-session.
Example: We have two sessions running on the same local server. A1 and A2. A1 will add a new notification, that should lead to an update of the notificationCount in A2. We retrieve both sessions as described above, update the notificationCount with a 'refresh in client'. We start a test microflow in A2 that retrieves notificationCount over the session association. Though we see that in A1, the 'count' attribute of the notificationCount instance with GUID X has been updated to 5, the same notificationCount instance we see in the debugger for A2 still reads 4.
My question is purely out of theoretical interest (practical ideas to the other thread please), as it made me realise how little I understand of how Mendix handles these kind of interactions.
Why are we seeing this behavior?
On websockets / client-server interaction: Why does the above not initiate a refresh of the given object in the appropriate client?
On sessions / memory: Why does the above change in instance X of an object by user A1 not lead to a change in that same instance X for user A2?