Disable repository caches?

[kring]

Hi,

Is there a way to globally disable the caches in the repository?

(Alfresco Community 6.1)

As far as I understand, it is possible to disable the repository caches (approximately 50 in total) one by one by overriding the appropriate beans that configures the caches, i.e. override the beans in tx-cache-context.xml like this:

For example, this bean

<bean name="propertyValueCache" class="org.alfresco.repo.cache.TransactionalCache">
  <property name="sharedCache">
    <ref bean="propertyValueSharedCache" />
  </property>
  <property name="name">
    <value>org.alfresco.cache.propertyValueTransactionalCache</value>
  </property>
  <property name="maxCacheSize" value="${cache.propertyValueCache.tx.maxItems}" />
  <property name="mutable" value="true" />
  <property name="disableSharedCache" value="${system.cache.disableMutableSharedCaches}" />
  <property name="tenantAware" value="false" />
  <property name="cacheStats" ref="cacheStatistics"/>
  <property name="cacheStatsEnabled" value="${cache.propertyValueCache.tx.statsEnabled}"/>
</bean>

could be changed into

<bean name="propertyValueCache" class="org.alfresco.repo.cache.NullCache">

I guess, I could do it like this (is that correct?) but if there is an easier way to disable all the repository caches in one go that would be more convenient.

The reason I ask this question is that I would like to try to run two (or more) Alfresco Community repositories in parallel with a load balancer in front - and this will not be possible as long as the repository caches are enabled, since this would lead to caches that are out of sync in the repository instances (and hence data inconsistencies).

Best regards

Andreas

[afaust]

Not all caches in Alfresco are used in the same way. It would be dangerous to blindly deactivate all caches in the Repository. Some caches hold singletons, like the resource bundles for I18n, service references, or resolved root nodes for specific data dictionary configuration folders.

You should also be aware that Alfresco already has some safeguards against inconsistent cached data, using entity versions for optimistic locking and transaction retry upon detecting stale data. This is used e.g. for data about nodes. So you may not even need to disable those caches to ensure data consistency - unless you want to avoid the overhead of the retry upon staleness detection.

As far as I know, the property system.cache.disableMutableSharedCaches should serve the purpose of disabling all caches dealing with mutable data. This should effectively disable the functionality of the transactional caches that push data into the global / shared cache, and ensure that the next transaction has to re-retrieve the data from the database since it is no longer shared across transactions.

[kring]

Hi Axel.

Thank you for your reply.

If I understand your response correctly this very is good news, i.e. when you say "So you may not even need to disable those caches to ensure data consistency - unless you want to avoid the overhead of the retry upon staleness detection", this basically means that it should be possible to make a cluster of Alfresco Community repository servers (where the repository instances do not need any special configuration with respect to their caches). So the only things needed are a load balancer, a common DB that all the repositories in the cluster can communicate with and a common filesystem to store the content (and also a common Solr server).

Does this setup sound like something that would actually work?

(and by the way - regarding the caching disussion above - I found your talk "The art of the cache" from Beecon 2017 (beecon.buzz) very helpful, so thank you for contributing with this presentation and the slides).

Best regards

Andreas

[afaust]

You can have a "simplified cluster-like" setup using Community Edition that way, yes. Notice that I said "may not even need to disable those caches" and in the examples referred to caches about node data. That does not mean that ALL caches use optimistic locking for staleness detection. E.g. caches for Namespace / QNames do not use such a mechanism - though it is not expected that QName / Namespace entries are actually deleted (and thus can cause staleness issues), the API of the QNameDAO actually supports the deletion use case.

Effectively, you will still have to test & disable & verify some of the caches to make such a scenario work in principle. Note that no matter what you do, your "cluster-like" setup will not support seamless failover / re-use of authentication tickets (e.g. in a load balanced ReST API call scenario), as tickets are only held in the in-memory caches and without an active cluster communication (like provided by Hazelcast in the Alfresco Enterprise Edition, or any 3rd party data grid / clustering module that someone may provide for Community) tickets will only be valid on the server on which they have been issued. There will also be issues with some advanced functionalities that rely on event-based activation, such as model / web script / message bundle deployment via Data Dictionary, which will only work on the server the action / event is triggered on and will not cascade to any other server in the "cluster-like" scenario.

[kring]

Ok - I will do some experiments and see, if I can get it working.

Just a comment regarding the issue you mention with re-use of authentication tickets - we are using external authentication in our setup, so I guess this will not be a problem. We handle the authentication via SAML in an Apache HTTP server that runs in front of Alfresco.

I will post the results of the experiments in this thread in case someone is interested in these.

Thanks a lot for your input.