My takeaway from your comments is that if I never flush ...
The problem is not a cache flush in general, but wild card flushes (which have to iterate over all the cache keys). Also note, that wild-card flushes on the cache stop as well all other operations on this cache (e.g. the flush from portal-procs above will block as well "your" harmless operation).
... then it's safe to use this caching.
Whatever "safe" means. When something is cached from the database, and the database is updated, but the cache is not flushed, stale results (incorrect) will be reported.
In general, it is better to use specialized caches with precise flush semantics (typically via API), not based on wild-card flushes. Many small caches are also better, since this leads to better concurrency. If there is only one cache, and this cache is locked, then everything comes to a halt. On our LEARN system, we have on average 320 locks per page view, all of these can bring all running threads to a full stop.
that ship has sailed unfortunately.
When your application is performance sensitive, an upgrade will help. Since acs-core is adapted to work with Oracle 19c, upgrading your core should be feasible. This is probably less effort than cherry-picking some changes to improve performance, increase security, etc. Let me know if I can help....
all the best -g
