Question

Application global properties

3

What's the best practice for setting and using a list of application-wide global properties? I've got a Properties type, listing things like server locations for particular tasks, configurable constants and parameters such as VAT rates, and so on. There would only be one object of this type and a form for updating it (a DataView). It would want to be visible from various places in different microflows.

asked 2009-09-18

Martin Bucknall

3 answers

Benny van Reeven · Answer 1 · 2009-09-20

There are at least two options for application-wide global properties: constants and a singleton settings type.

Constants are a set of constant values that are used in the appliation for various purposes. Examples of constants include locations and passwords for external services, as well as database connection strings.

Constants are design-time configurable, i.e., they can be configured staticly in the Modeler (for development and test modes) and in your application.conf file (for acceptance and production modes). Their values can never change during the operation of the MxRuntime.

A singleton settings type is a singleton type (i.e., a type of which only one instance exists) that contains settings for your application. These settings are run-time configurable, by allowing the user to edit these settings in, e.g., a data view. The Properties type that you describe is an example of this pattern. As there are no explicit singleton types in the Mendix technology, you need to manually ensure that exactly one instance of your settings type exists.

As of version 2.4.3, it is possible to create a "Settings" menu item that directly shows the settings data view form. This is accomplished by creating a menu item that triggers a microflow that retrieves the settings object and shows it in a form.

Concluding, if your settings need to be configurable at run-time, a singleton settings type is the recommended best practice for application-wide global properties. Otherwise, use constants.

Pieter van de Braak · Answer 2 · 2014-11-18

@Samet.

There are two things, first off the databases uses a cache which remembers if the same querie has been done recently. If so it will retrieve the object from its cache greatly reducing the amount it takes to retrieve the object. However this still means you have to cross the communication layer with the database. I assume that mendix uses it's own object cache but this cache is not likely to survive two different microflow calls/webservice calls. This would not make any sense since 1 webservice call could influence the other.

What you could do is have a java pointer that keeps the object object in memory and retrieve it from there. This does however raise the question when do i clean up this object/change this object?

Basically this means that you build your own cache in java.

Samet Kaya · Answer 3 · 2014-11-18

Just bumping this thread to know if there is any change on this subject. We're building an app which is serving a webservice, which is called by multiple webservice users. Our app needs to serve more than thousand calls every minute and I'd like to know if there is any possibility to remain an object in memory. Instead of retrieving it thousand calls a minute.

There is no possibility to associate this object to the user, because the webservice user logs in and after the call his session is destroyed and you will lose access to the object in the database.

Is there a way to hold a specific settings object in memory, which could be retrieved by multiple different users without a database call?