RecordList variable with application level scope

RecordList variable with application level scope

Hello All,

I jave a bath process that creates and updates a record list.
This record list need to be accessible from other batch processes and HTTP requests.. but without persisting data into database.

I am thinking about having a RecordList type variable with application level scope.. i.e a variable created at application start-up and assessible from all application areas..

Is there a way to do this with the platform?


Hi Alex,

My first recommendation is for you to consider if you really want to keep the record list in memory all the time, instead of storing it somewhere. There might be unnecessary performance hits because of that, as the list grows...

Still, if you don't want to store it in the database, you could store it on the filesystem somehow.

If that still doesn't suit you, I'm not really sure how you would go about doing such a thing - probably you would have to create such a variable in an extension, and manipulate it through an extension as well (or at least have methods to retrieve, create and update it).

Let us know your thoughts, and if this helps.


Paulo Tavares
The list will not be long - 1000 records the most - so the overhead due to its size should not be a concern.

My thoughts are that if such Record Lists are not supported directly, then I should go with a regular entity..
simply in my case there is no really a need to persist this data and such of DB I/O is an overhead..

In general I think such application scope variables should be supported by the platform directly. So if such feature is not available, then I will submit it as an idea in the wisdom of the crowds. What do you think?
Hi Alex,

Well, you can do it, but as I see batch processes being implemented in the Agile Platform is by a timer which, in each run, does the following:

- Check if there's still work to do in the database;
- Get status from database;
- Resume from status, and execute X amount of batch operations (depending on their length, since the timeout for the timers is 15 minutes. I've done it with batches of 5.000 operations, for instance);
- Store status in the database;
- Call timer again.

This way you really only do database I/O two or three times per batch execution, and the rest is all a local variable.

Does this model make sense to your scenario?

Either way, you can definitely suggest it in the Wisdom of the Crowds, but given that I do not recall anyone ever mentioning such a use case, maybe I'm missing something here.


Paulo Tavares