Beware of static code on multi IIS worker process environments


On farm environments that use a network load balancer, to distribute the HTTP requests through the several Hub Nodes, or in Hub Servers that have web garden activated or have more than one worker process running in IIS to serve those requests, the use of static code, like variables, objects or methods, may reveal unexpected behavior or errors.

This happens because under these conditions, requests may be answered by different worker processes and since the process memory of those worker processes isn't shared, static content may be initialized and manipulated on one process, but not on the others, leading to missing or empty objects or data.

Hence, when integrating customized source code into OutSystems applications by the means of Integration Studio, beware for the use of static code and try to avoid it always.

If for some reason you can't get ride of the need to use static code you must unsure that the application runs only in one worker process. In a load balancer environment, you may have to restrict that application to one Hub Node only, whereas in a single node environment, either make sure the application pool uses only one worker process, or the application uses a dedicated application pool.

Hope this information is helpful.


Miguel João
Hi Miguel:

I had two questions about this topic:

1. Is this valid for code that runs inside timers?

2. If we garantee that the static classes are initialized in both processes the same way, shouldn't it also be transparent?


Miguel Baltazar
Hi Miguel,

Answering your first question, this issue is only relevant if you are using static variables to store data between requests (or Timer executions).

In the OutSytems Platform, Timers are executed by the Scheduler Service which runs on the Hub Nodes. Hence, any Hub Node may execute a specific Timer and its eventual static variables will exist only on that Hub Node. Other nodes will therefore have no access to the data on that variables. Instead, they will have their own variables with different values in a different machine and/or process memory space.

Concluding, this is valid also for code that runs inside Timers, unless you have your Scheduler Service running only in one node, in which case that will be the only node running Timers and all executions will share the same process if and only you have a single worker process. So, this solution wouldn't scale neither horizontally, nor vertically.

Answering your second question, it all depends on what you do with the static classes. I'm assuming you want to use them to store state between requests and/or Timer executions. If that's the case, this is not transparent. Despite the initializations, the requests and Timer executions will occur on different worker processes and/or Hub Nodes, so no state will be shared between them.

However, if you are using these static classes just because and they have no relevant state to share between requests and/or Timer executions, then you can use static classes with no problem.

So as for your second question there is no yes or no answer, it depends.

My advice if you want to share data between different requests and/or Timer executions is for you to use the database for this purpose. That's the only thing that is sharable in a web environment that may grow horizontally or vertically, with farm environments or different worker processes (web garden).

Hope this info is useful,

Rodrigo Castelo
Can I assume that all that has been written here will also apply 'tranparently' to the JAVA version?

IIS can have more than one worker process to serve requests. JBoss can probably do the same, right?

Duarte Gouveia
Hi Duarte.

Yes, the same applies to Java. If you have a multiple hub node environment the behavior will be the same as the one thoroughly described by Rodrigo Castelo.