<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Disable repository caches? in Alfresco Forum</title>
    <link>https://connect.hyland.com/t5/alfresco-forum/disable-repository-caches/m-p/42310#M17679</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;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&amp;nbsp;in the examples referred to caches about node data. That does not mean that ALL caches use&amp;nbsp;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Effectively, you will still have to test &amp;amp; disable &amp;amp; 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&amp;nbsp;action / event is triggered on and will not cascade to any other server in the "cluster-like" scenario.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 06 Mar 2019 21:00:37 GMT</pubDate>
    <dc:creator>afaust</dc:creator>
    <dc:date>2019-03-06T21:00:37Z</dc:date>
    <item>
      <title>Disable repository caches?</title>
      <link>https://connect.hyland.com/t5/alfresco-forum/disable-repository-caches/m-p/42307#M17676</link>
      <description>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-cach</description>
      <pubDate>Tue, 05 Mar 2019 09:24:33 GMT</pubDate>
      <guid>https://connect.hyland.com/t5/alfresco-forum/disable-repository-caches/m-p/42307#M17676</guid>
      <dc:creator>kring</dc:creator>
      <dc:date>2019-03-05T09:24:33Z</dc:date>
    </item>
    <item>
      <title>Re: Disable repository caches?</title>
      <link>https://connect.hyland.com/t5/alfresco-forum/disable-repository-caches/m-p/42308#M17677</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Not all caches in Alfresco are used in the same way. It would be dangerous to blindly deactivate all caches in&amp;nbsp;the Repository. Some caches hold singletons, like the&amp;nbsp;resource bundles for I18n, service references, or resolved root nodes for specific data dictionary configuration folders.&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;As far as I know, the property&amp;nbsp;&lt;SPAN style="color: #727174; background-color: #ffffff;"&gt;system.cache.disableMutableSharedCaches should serve the purpose of disabling all caches dealing with mutable data. This should effectively&amp;nbsp;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.&lt;/SPAN&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 05 Mar 2019 12:13:19 GMT</pubDate>
      <guid>https://connect.hyland.com/t5/alfresco-forum/disable-repository-caches/m-p/42308#M17677</guid>
      <dc:creator>afaust</dc:creator>
      <dc:date>2019-03-05T12:13:19Z</dc:date>
    </item>
    <item>
      <title>Re: Disable repository caches?</title>
      <link>https://connect.hyland.com/t5/alfresco-forum/disable-repository-caches/m-p/42309#M17678</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi Axel.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thank you for your reply.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Does this setup sound like something that would actually work?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;(and by the way - regarding the caching disussion above - I found your talk "The art of the cache" from Beecon 2017 (&lt;A class="link-titled" href="http://beecon.buzz/" title="http://beecon.buzz/" rel="nofollow noopener noreferrer"&gt;beecon.buzz&lt;/A&gt;) very helpful, so thank you for contributing with this presentation and the slides).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Best regards&lt;/P&gt;&lt;P&gt;Andreas&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 05 Mar 2019 20:27:57 GMT</pubDate>
      <guid>https://connect.hyland.com/t5/alfresco-forum/disable-repository-caches/m-p/42309#M17678</guid>
      <dc:creator>kring</dc:creator>
      <dc:date>2019-03-05T20:27:57Z</dc:date>
    </item>
    <item>
      <title>Re: Disable repository caches?</title>
      <link>https://connect.hyland.com/t5/alfresco-forum/disable-repository-caches/m-p/42310#M17679</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;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&amp;nbsp;in the examples referred to caches about node data. That does not mean that ALL caches use&amp;nbsp;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Effectively, you will still have to test &amp;amp; disable &amp;amp; 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&amp;nbsp;action / event is triggered on and will not cascade to any other server in the "cluster-like" scenario.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 06 Mar 2019 21:00:37 GMT</pubDate>
      <guid>https://connect.hyland.com/t5/alfresco-forum/disable-repository-caches/m-p/42310#M17679</guid>
      <dc:creator>afaust</dc:creator>
      <dc:date>2019-03-06T21:00:37Z</dc:date>
    </item>
    <item>
      <title>Re: Disable repository caches?</title>
      <link>https://connect.hyland.com/t5/alfresco-forum/disable-repository-caches/m-p/42311#M17680</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Ok - I will do some experiments and see, if I can get it working.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I will post the results of the experiments in this thread in case someone is interested in these.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks a lot for your input.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 07 Mar 2019 09:20:06 GMT</pubDate>
      <guid>https://connect.hyland.com/t5/alfresco-forum/disable-repository-caches/m-p/42311#M17680</guid>
      <dc:creator>kring</dc:creator>
      <dc:date>2019-03-07T09:20:06Z</dc:date>
    </item>
  </channel>
</rss>

