Alfresco Content Services 6.2 introduces the concept of eventual consistency to overcome the scalability limitations of in-transaction indexing.
Here’s some background information on the evolution of eventual consistency in Alfresco:
- Alfresco Enterprise 3.x supported a transactional index of metadata using Apache Lucene.
- Alfresco Enterprise 4.0 introduced an eventually consistent index based on Apache Solr 1.4.
- Alfresco One 5.0 moved to Solr 4 and also introduced transaction metadata query (TMDQ). TMDQ was added specifically to support the transactional use cases that used to be addressed by the Lucene index in the previous versions. TMDQ uses the database and adds a collection of required indexes as optional patches.
- Alfresco One 5.1 supports a later version of Solr 4 and made improvements to TMDQ.
- Alfresco Content Services 5.2.x supports Solr 4, Solr 6, and TMDQ.
- Alfresco Content Services 6.x supports Solr 6, and TMDQ
When changes are made to the repository they are picked up by Solr via a polling mechanism. The required updates are made to the Index Engine to keep the two in sync. This takes some time. The Index Engine may well be in a state that reflects some previous version of the repository. It will eventually catch up and be consistent with the repository (assuming the repository is not constantly changing).
When a query is executed, it can happen in any one of the following ways:
- By default, if the query can be executed against the database, it will be.
- If not, the query goes to the Solr index.
There are some minor differences between the results. For example, collation and how permission are applied. Some queries are not supported by TMDQ, for example, facets, full text, in tree, and structure. If a query is not supported by TMDQ, it can only go to the Index Engine.