Some of the common reasons why DXP may need to access the database instead of the cache

Issue

• Why there are so many journalarticle calls in the database rather than in the cache?

Environment

• Liferay DXP [all versions]

Resolution

• A JournalArticle object in the database represents a Web Content Article, so the query would run any time that Liferay needs to fetch a Web Content Article for any reason if it wasn’t able to find the Web Content Article in the cache. It would be extremely difficult to list out all the possible scenarios under which this query could run, as there are a large number of reasons why Liferay might need to fetch a Web Content Article. However, a non-exhaustive list would include the following:

  • The user is visiting the Site Administration > Content & Data > Web Content Menu. In this case, potentially up to n JournalArticle queries will need to be run, where n is the amount of Web Content that the user sees on the page.

  • The user attempts to edit a Web Content

  • The user visits a page with a Web Content Display portlet(s) and/or an Asset Publisher portlet(s) that are configured to render Web Content. In this case, up to n JournalArticle queries will need to be run, where n is the number of Web Content displayed across the portlets on the page.

  • The Web Content article has breached its expiration date or its review date, and the automated process is running to expire it or send out the review notification for it.

  Remember, this is not a comprehensive list; these are just some of the most common scenarios that might help here. Also remember, Liferay will always attempt to fetch the article from the cache first, and it will only run the JournalArticle query if the article couldn’t be found in the cache.

   

Additional Information

• There are some of the most common reasons why the JournalArticle may not be in the cache:
  
  • The JournalArticle simply had not yet been read from the database at the time of the query. It should only happen once after startup per JournalArticle, and then never again until the portal is restarted. However, it could be possible if users are frequently adding new JournalArticles.
  • The JournalArticle was previously evicted from the cache because the cache was too small to hold all the JournalArticles. This could happen if the number of JournalArticles in the database exceeds the maxElementsInMemory value defined in their cache configuration. This will cause JournalArticles to be evicted from the cache whenever the cache size gets too large. If this is the case, it could be resolved by tuning the cache to have a larger maxElementsInMemory value, and possibly also increasing the JVM’s allotted memory to compensate for the increased cache size. 
  • The JournalArticle was previously expired from the cache because it sat unused for too long. This could happen if the JournalArticle is sitting idle in the cache, never being fetched, for longer than the timeToIdleSeconds value defined in their cache configuration. If this is the issue, then users can tune the cache by increasing the timeToIdleSeconds value. 
  • The JournalArticle was previously evicted from the cache because it had been updated. Whenever the JournalArticle is updated, it is immediately evicted from all caches and must be re-fetched from the database the next time. This might be the culprit if users have some sort of custom code or automated process that is frequently updating JournalArticles.
• The above information is from a product standpoint, kindly review this Introduction to Cache Configuration article. Please be noted that Liferay support is limited to providing any specific suggestions or recommendations about what cache configuration values users should set. However, we have a different channel named the "global services team" who can assist users further with this, as this comes under their scope of work.