Helping you drive digital innovation
Subscribe
RSS Feed of the Mendix Blog
Thanks for Subscribing

Keep an eye out for Mendix resources coming straight to your inbox.

Persistence is futile

on June 12, 2012

Share:

Persistence is futile. No, that is stretching it too far, but at least it is optional in the Spring 2012 release of Mendix (a.k.a. version 4). In earlier versions all data that you wanted to manipulate in your application was stored in the database. However, when you use entities for importing data from a web service, for example, it makes much more sense to store objects in memory only. Now you can!

Entities have a new property called ‘Persistable’. By default it is set to ’yes’, corresponding to the situation in the old days. Setting it to ’no’ changes the entity to a non-persistable entity. Such an entity is never stored in the database (a database table is not even created for it) and it is drawn in orange instead of blue.

Non-persistent entity

Non-persistent entities are orange.

If you call a web service and map the result to non-persistable entities all objects are created in memory. This is considerably faster and there is no need to clean the database after you are done with the objects. Integrating applications can be achieved more efficiently and without replicating data now.

Mapping to non-persistent entities

Mapping to non-persistent entities.

We did not stop there. The behavior of persistable entities – the blue ones – has been optimized as well. Creating an object no longer inserts a row in the database. The insert happens at commit now. This helps performance and gets rid of the empty rows in a grid that appear if someone presses a ’New’ button and then navigates away before saving or canceling the subsequent dialog.

Note that object actions like commit, rollback and remove work for both persistent entities and non-persistent entities. The behavior is the same except for that fact that the database is not contacted for non-persistent entities.

Now that we keep more objects in the server memory, we need a way to get rid of objects that are no longer used. Fortunately, you do not have to worry about this. An intelligent garbage collector takes care of this.

Plastic Truck

The garbage collector cleans up unused objects.

In summary, there is a lot less database access while manipulating objects. This means applications respond faster and the database only stores data that really needs to persist across sessions. And to those objects that are not used anymore we say: “Resistance is futile. You will be garbage collected!”

Tags:

Subscribe to Our Blog

Receive Mendix platform tips, tricks, and other resources straight to your inbox every two weeks.

RSS Feed of the Mendix Blog
Arjan van IJzendoorn

About Arjan van IJzendoorn

Arjan is a member of the Mendix R&D department. He started developing the Mendix Modeler a long time ago and is still working on that application most of the time. Currently, he focuses on the modeling side of pages and widgets, with the occasional excursion into the rest of the Modeler.

| Community Profile
  • Arjan, the fact that a row insert happens at commit time is just as big a deal as the addition of transient objects; both are fantastic enhancements.

    We are in the process of upgrading a 2.5 legacy system to version 4, for these reasons amongst some other obvious ones.

    I’ll be doing a blog post soon on what other patterns you can now apply with transient objects, which didn’t make sense in the past. 

    The modeler is improving at every step, and I would say that resisting the new way of developing is futile. 🙂 The next step in the evolution of development is modeling.