Are all NPE objects associated to the CurrentSession kept as long as the session is active?

0
Hi fokes,   I did some reading on Mendix State & Garbage collection (part 1 and 2 of https://www.mendix.com/blog/the-art-of-state-part-2-garbage-collection/). Very good reads by the way. A question I have is concerning $currentSession and the Garbage Collection. I read that the GC works with subscriptions on objects that are not removed by GC. Then I read “ Objects representing $currentUser and $currentSession are always subscribed to within the Mendix client, as they live as long as users use the app and might be needed by the application at any time.”   Also I read:  Which Objects Are Kept in the State? All subscribed objects are kept in the state. All objects “reachable” from subscribed objects are kept if they fall into one of these categories: Non-persistent objects, because they can’t be found in the database. Persistent objects which are created but not yet committed, because they aren’t in the app’s database yet. Persistent objects which are committed but contain changes, because changes aren’t in the database yet — but a microflow might need them.   Do I understand correct that because CurrentSession is not removed (unless user logouts or is inactivie for a certain amount of time) all the objects associated to the session are not removed aswell? In our application we associate quite a bit of NPE objects to the session of the user, so I guess this can take up quite a bit of memory on the Client after using the application for a while? So I guess it would be wise to explicitly remove these NPE objects using logic in microflows when these NPE objects are no longer required?   Thanks!   Tim  
asked
1 answers
4

Hi Tim,

You are completely right, the garbage collector will skip these objects and the Client's memory may pile up with objects associated to the Session.

So rule of thumb: use as little as possible NPE associations to User or Session, preferably none.

If you do: try to minimize the objects, preferably use one object (retrieve list and get head), to minimize load.

I'm curious to the use-case where you would require to have a list of objects associated to user/session. Could you elaborate on that?

Maybe you could then consider a cleanup microflow, although it might be difficult to find the right triggers, as navigating to any other page might be one.

Good luck!

 

answered