When using notification-based invalidation on Local Cache, the ttlValue time-out will still invalidate cache items and thus forcing a fetch from the cache cluster on the next request.
For example, in the configuration below, items will time-out after 300 seconds but will also be checked for invalidation notifications on the cluster every 60 seconds (such as if they were removed):
<dataCacheClient name="default">
<localCache isEnabled="true" sync="NotificationBased" objectCount="100000" ttlValue="300" />
<clientNotification pollInterval="60" />
</dataCacheClient>
I have a set of objects which are immutable - i.e. they do not change. This means that they never need to have a timeout-based invalidation to "refresh" themselves.
This essentially means that immutable objects will unnecessarily be removed from the Local Cache. If these items are numerous, there could potentially be noticeable performance degradation, especially when thousands of items are needing to be read.
When setting it to zero in the DataCacheLocalCacheProperties constructor, I get the following exception:
An exception of type 'System.ArgumentException' occurred in Microsoft.ApplicationServer.Caching.Client.dll but was not handled in user code
Additional information: Time-out should be a positive value.
The other option I have to set an unreachable number.
Why are we not permitted to have Local Cache with a zero timeout?
I am using Azure In-Role Caching (colocated).
You cannot specify zero as the ttlValue as that would mean that items are never cached.
Your question then is really "why is using zero as the ttlValue not used as a special case to indicate that items should never be invalidated?" which could only be answered by Microsoft.
If you set the ttlValue to int.MaxValue, then the items will not invalidate for 68 years, which should be long enough.