Caching and AOP in Mendix: is there a uniform or standardized approach for server-side caching within a Mendix application?

Question

Using the Mendix Business Modeler to build web-applications is fundamentally different than developing web-applications using technologies like Java/Spring/JSF. But, I'm going to try to compare the two for the sake of this question:

In a Java/Spring based application, I can integrate my application with the 3rd party product Ehcache to cache data at the method level. For example, I can configure ehcache to store the return value for a given method (with a specific time-to-live). Whenever this method is called, ecache will automatically check if the method has been called previously with the same parameters and if there is a stored return value in the cache. If so, the method is never actually executed and instead the cached method return value is immediately returned.

I would like to have the same capabilities within Mendix, but in this case I would be caching Microflow return values. Also, I don't want to be forced to add actions all over the place explicitly telling the Microflow to check the cache. I would like to register my Microflows for caching in one centralized place, or simply flag each Microflow for being cached. In other words, this question is just as much about the concept of aspect-oriented-programming (AOP) in Mendix as it is about caching: is there a way to get hooks into Microflow invocation so I can apply pre and post execution operations? In my opinion the same reasons why AOP has it's place an purpose in Java exist in Mendix.

Suzy

Answer 1

When working with the Mendix application it tries to do as much for you as possible, in this case that means that the platform already has an object cache to keep all objects that need caching. Internally the Mendix platform uses Ehcache to do that.

However it is not really possible to influence that cache as you would normally do in Java/Spring.This is due to all the functionality of the Mendix Platform, that already tries to cache all objects as efficiently as possible.
Every object you create is always added to the cache. When working with that object it stays in cache until the Platform detects that the specific object can no longer be accessed either through the UI or a microflow. There are also API calls available that instruct the platform to retain the object in cache regardless of it's usage. But that doesn't provide you with the flexibility as you asked for.


But specifically on your question, my initial response would be: Why would you want to cache a microflow output?
Objects are already cached in memory, and the browser client only refreshes the cache when instructed. Any objects that you are using will be cached. Also when looking at most of the microflows that we use, I don't think it is likely that I would want to cache the output instead of re-running the microflows. Due to the design of the majority of the microflows I think it is likely that most microflows can return a slightly different output every time you execute it.

There are many listener classes you can subscribe to in the Mendix platform that allow you to trigger something in addition to the default action. But that would require some detailed knowledge of the current behavior.
For example you can override the login action, but if you don't perform all the correct validations you could make the login process less secure.

Orthogenetic

Thanks for the response. I didn't know that Mendix already used ehcache in the way you described. I completely agree that I definitely wouldn't want to cache all or most Microflow output. This would render an application pretty pointless. But for some Microflows which aren't side-effectual and perform a specific type of activity, I think I might want this capability. – Suzy

For example, if I have a series of Microflows (and sub-microflows) which build a web-service request object, submit the request, then extract relevant data from the web-service response, and I happen to know that the return data itself is inherently cacheable, then what is the best way to prevent the application from expending unnecessary resources and making the round trip? I suppose I was just looking for a way that this problem could be solved generically and then applied whenever it's explicitly requested. – Suzy

There's no generic mechanism for this in Mendix, so in such a case where you can cache values and the performance gain is actually relevant you'd have to resort to building it yourself. A fairly generic solution could be built using Java actions that can call microflows and store return values in some sort of key/value store. Btw, note that latest versions of Mendix no longer use Ehcache internally. – Yarber