Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance Caching Current Locale #5096

Merged

Conversation

thomaslow
Copy link
Collaborator

@thomaslow thomaslow commented Apr 27, 2022

Contributes to:

On many occasions, e.g., when translating messages, the method LocaleHelper.getCurrentLocale is called. If a user is logged in, this request will trigger a database query for the current language setting of the user, see Line 84. Naturally, issuing a database query for each #{msgs.something} will reduce performance significantly.

In theory, this database query could be cached by Hibernate. Unfortunately, Hibernate caching is currently not working in Kitodo:

  • the Hibernate first-level cache is not used, because Hibernate sessions do not persist for longer than a single database query, see most methods of BaseDAO, and the first-level cache is bound to the current Hibernate session
  • the Hibernate second-level cache is enabled globally, but requires the annotation @org.hibernate.annotations.Cache for each Bean, which are missing, see Documentation:
By default, entities are not part of the second level cache and we recommend you to stick to this setting.
[...]
Use the @org.hibernate.annotations.Cache annotation for this purpose.

Even with database caching enabled, one could argue that each #{msgs.something} should still not require a full re-evaluation of the Hibernate query framework. In my opinion, the current user locale should be cached in memory for each request.

The proposed pull request caches LocaleHelper.getCurrentLocale via a simple request scoped cache implementation using FacesContext, meaning the cache is cleared after each HTTP request. Caching improves performance significantly (together with #5095):

Drawbacks

Caching via FacesContext could be argued to not be a very clean way of implementing this. Ideally, such information should be cached via beans that are annotated with @RequestScope. However, I'm not aware of any other way to introduce request scope to low-level static service methods like this. I suppose this is a JSF architectural design issue. Any suggestions are welcome.

Copy link
Collaborator

@markusweigelt markusweigelt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great idea to cache within the RequestScrope. From my side the code and documentation fits except of the small comment.

private static final String ATTRIBUTE_NAME = "RequestScopeCacheHelper";

@SuppressWarnings("unused")
private static final Logger logger = LogManager.getLogger(RequestScopeCacheHelper.class);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this logger? If not then I suggest to remove it.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not needed. Removed

Comment on lines 21 to 22
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As there is no Logger anymore this imports are not needed anymore.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had overlooked thx

@Kathrin-Huber Kathrin-Huber merged commit 64b39a0 into kitodo:master May 13, 2022
@thomaslow thomaslow deleted the performance-caching-current-locale branch May 19, 2022 10:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants