Site Property behaviour

Site Property behaviour

I would like to know some more about site property behaviour in an espace. In particular the caching behaviour and when exactly to use the TenantInvalidateCache action. I know that if you use a site property as a counter for something that you will have to use the TenantInvalidateCache action to make sure the espace doesn't take the cached value of the site property. I was also wondering why these site properties have these caching behaviours and if this is really needed.

Jan Haentjens.
Dear Jan:

Site properties were originally designed to allow global configuration of multi-tenant applications, which shared the same code but needed different global configurations variables to store the values for each tenant. In single tenant applications they should be used as a place to store parameters that are accessed by the whole application but seldom change and usually require user intervention.

This being said, the behaviour of a site property is the following:

- When you read it for the first time on a server it is loaded from the database into the cache. Next time you read it, it will be read from cache until the cache is invalidated (using TenantInvalidateCache).

- If you write something to that site property, it will use a "write through" method updating the cache on that server and the database. The problem you describe appears if you have a cluster installation and other hub nodes have the old value in their cache. This is why, in a single server installation you do not need to use the TenantInvalidateCache action, but it is highly recommended because you might need to upgrade your installation and you want your applications to continue working properly!

You should not use site properties to implement highly changeable values like counters, because you end up having concurrency issues when updating their value. If two threads try to read the value and add one, you might have a race that will result in errouneous behaviour. If you use a database table (getforupdate) or a session variable, this problem will not occur.

Regarding the last doubt about why is this behaviour implemented like that, the main reason I have for you is that we perceive and allow Site Properties to be used as normal read-only memory variables. To allow this, we would assume read time would be memory time and not database time, thus the need for caching.

I hope this helps.