ISession.getData() API

3
With the introduction of Mx5.21 it is much easier to retrieve the session of a user. See the documentation here: https://world.mendix.com/display/refguide5/ISession.getData%28%29+API+usage Is my understanding correct that with this option I could send messages to a user far more easier? Up untill now it was hard to send a popup message to a logged in user. From the documentation I now could retrieve the currentsession of that user and create a microflow that sends a popup message to that specific user of that session. Or am I misreading the documentation here. If I am correct that would open up a lot of new possibilities :) . Regards, Ronald
asked
2 answers
1

The change that is described in this page is a different way on how to keep non-persistent entities in memory.

In the current Mx5 version you can use the retain() and release() function to override the Mendix garbage collector. This will allow you to keep non-persistent objects in memory for a longer point in time.
This would allow you to build a similar process as you are describing where you have a Microflow and/or Java action checking if there are non-persistent entities and show these to the user.
In Mx5 this would require you to code, associating the record with the System.Session entity previously didn't work for the simple reason that the Session entity would not remain in memory (the platform keeps the session info, but not the actual object) therefore any associated entity would be garbage collected.
Alternatively you could associate the non-persistent entity with System.User, but that could be confusing at times if you have user(name)s that are logging in with multiple sessions.


In Mx6 the platform becomes cluster-aware, and will have the ability to share data across servers. However as the documentation page states the retain/release function only effect the local cache. When the user switches over to a different platform instance you would still loose your data, since it was only retained in memory of the original instance.
The new method of associating data with the session should resolve this. To make the platform cluster aware you need to persist the session info (Using the IsClustered option). The simplified explanation of the difference is that in Mx6 a System.Session entity object will now always stay in memory just like the user.
So this doesn't really introduce any major new features, but it does make it significantly easier to hold data for the duration of the session.


In other words in Mx6 with IsClustered=true, every user that logs in will have an existing record in the System.User table, and the platform will create a new record in the System.Session table. These two objects will stay in memory for the duration of the session. Conform the default garbage collection behavior, any object associated to either of these two objects will stay in memory as well. (This applies to both persistent and non-persistent objects).
(But please be aware that because of this you will also have to control garbage collection by either deleting these objects, or resetting the associations to empty.)

See also this page for some additional info regarding default garbage collection. The Java explanation applies to Mx5 only, the rest also applies to Mx6
https://world.mendix.com/pages/viewpage.action?pageId=16714069#TransientObjects&GarbageCollecting-RetainedObjectsinJava

answered
3

From my understanding, you are reading too much into this. You can now easier store variables for a session, and they can be retrieved differently. You cannot configure a Show Message activity to send a message to a session. All communication from the JavaScript client is still initiated by that client, not by the server.

answered