Keeping a global mutable variable in a Mendix application
For a project I need to compare a sequence number of an object with the previous one and only continue when they match. I do not want to retrieve the previous object from the database every time I process the new object due to performance reasons, so I need a way to store the previous sequence number. My proposed solution looks like this: Create a java class with a static variable holding the sequence number which is initialized at -1. Create 2 java actions, a 'get' and 'set' action. The 'get' action looks up the static variable in the static class, the 'set' action sets the variable to whatever is passed as a parameter. When the new object is retrieved in a microflow to start processing, first the 'get' action is called and the new sequence number is compared to the returned number. If the returned value is -1 then obviously the sequence number has to be obtained the expensive way, i.e. by a database call on that object sorted by sequence number with highest number first. If the comparison succeeds, then the new object is processed and the 'set' action is called with the new sequence number. My question is, is there any better way to do this? This solution is easy to implement but seems somewhat overly complex. I'd like to keep as much of the logic in microflows as possible.
Sebastiaan van den Broek
Bumping my old question since I can now effectively do this in 4.0 (beta), I can just create a transient object!
To prevent the object from being garbage collected when there are no more references to and from it, I can retain it in a java action with getContext().getSession().retain(object) and it will not be garbage collected throughout my session unless I call getContext().getSession().release(objectId)
I will still need to save the identifier in a static variable somewhere so I can retrieve my object with Core.retrieveId(getContext(), objectId) but I can simply return the object to a microflow and do the regular stuff with it in an easier way.
Sebastiaan van den Broek
How about creating a MetaObject which you somehow make unique (constraints etc) and then ONLY editing/reading that object via a microflow which has "disallow concurrent execution" (to avoid race conditions).
AFAIK there is no way in which you can keep mutable state in memory. The runtime was developed so that all state was preserved in the database. If you want to keep state in memory I believe you're stuck with Java.
Just don't forget to synchronize the variable to account for race conditions ;)