Multiple espaces and effects on site-properties

Multiple espaces and effects on site-properties



I have 2 espaces (A & B)
A uses B for some authentication.

In B I have a to impersonate the user or not.

testing the change in site-property in B it works.

testing with A and changing B's site-property I don't see any change at all, although the the site property has been changed.
How can I fix this?

Or am I missing something totally obvious :)

Hello Joost

You're actually hitting on somewhat unexpected behavior of the Agile Platform related to site properties cache in consumer-producer referenced espaces. The behavior is a side-effect of a by design architecture, in the reference model and how Site Properties are handle.

The Site Properties are stored on the database, but for performance issues, whenever they are used by the running application, it will not always load them fro mthe database. In fact, on the first time it loads the Site Property, it will be saved on the in-memory cache of the running application, which is isolated by espace. This cache is kept until the application is reload (through a IIS or JBoss restart or recyvcle, or after a new version deployment, or re-deployment) or when specifically issued the TenantInvalidateCache built-in action.

This feature has its drawbacks, like in the scenario you're reporting, when changing the Site Property of B, only B will actually acknowledge that change, while it's consumer A will not reflect the change on the Site Property. This happens because when the Site Property is changed on Service Center, it will start a TenantInvalidateCache on B, but not on it's consumer, and thus A will continue to use the cached value in A's application domain memory.

So, how can you solve this?

It's easy. You'll need to force a cache reload on A, which can be accomplish by any of the following operations:
  • Re-deploy espace A: in Service Center, use the Re-Deploy published version, which will broadcast to all the environment's Front-Ends to re-deploy that espace on the active Front-Ends web server, using the last compilation files of this espace, which will force the reload of the espace
  • Re-publish the espace A: in Service Center, if you upload and publish or use the Publish button for the running version, you'll recompile espace A again, and deploy it on all active Front-Ends of the environment, which will force the reload of the espace
  • Recycle the worker process (in .NET): in IIS, you can access the Application Pools list, identify which application pool is running espace A, and force a recycle (right-click on the application pool and choose recycle). This will reload ALL espaces that are deployed on that Application Pool (if it's OutSystemsApplications and you haven't customized it, then this will have all your espaces).
My suggestion is the first option, since it's faster and it will only impact espace A.

Hope this information helps


Miguel Simões João


Thanks for the answer although it is a tad dissappointing ;)

The usefullness of are non-existent now when using multiple espaces.
Time for an idea ;)

Hi Joost,

Site properties shouldn't be changed often, they're not designed for that purpose, they're meant to be relatively static elements in the runtime.
To solve your problem you can use Global Settings from Enterprise Manager.


I agree they shouldn't change often. however they can be changed and thus my expectations are valid.
Imho, the site properties are used for some global setting a log-level, a webservice url etc, debugmode.

they will not change often, but if the so-called shit hits the fan, you want to tweak some setting without doing cumbersome republishing/resetting of IIS.
as for your enterprise manager suggestion. we don't incorporate enterprise manager in every solution, because we don't have any need for it.