- The system uses Hibernate for database persistence. It provides 1st level and 2nd level EhCache cache.
- The system has its own caching mechanism for resources such as settings, labels and generated content. Almost everything that does not change often or accessed frequently is cached. The internal cache removes least accessed elements when it is full and expired elements.
- The system tells browsers to cache all downloaded content for 1 year. When the content needs to be refreshed, the system alters URLs by increasing resource version (appended to URL effectively making it a new URL) which forces browsers to fetch and cache everything again.
Caching is extremely good for the performance but database changes cannot be made while the system is running. Because of 2nd level EhCache and internal cache the system is not aware of any manual database updates and will try to persist stale data which on some occasions may even ruin the database state. The changes must go in through the system API which also updates the cache.
Some of the services to further improve the performance also store Hibernate domain objects in an inthernal cache. When an object is needed, the internal cache is checked firts and the 2nd level EhCache cache after. This eliminates database hits by the 2nd level EhCache query cache, which is likely to take place on most of the calls as the query cache is invalidated after each write to the database. When an object is requested, the internal cache may return it and prevent the database read by the query cache. The Settings service is the perfect example as it frequently reads and writes various settings. Domain objects get stored in the internal cache and in the 2nd level EhCache entity cache, which increases memory footprint. On occasion when memory is an issue or read-through ability is needed, the internal cache may be swithed off or reconfigured.