[
https://issues.apache.org/jira/browse/FC-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18007646#comment-18007646
]
Ben Manes commented on FC-327:
------------------------------
Search is a bit confusing because a cache is a subset of the data, but search
typically needs the full data to be useful. That often means a partial replica
of the searchable fields (e.g. ElasticSearch), querying that index for the
entity ids, and a multi-get to the cache to load the entries. Then the cache
mappings stay independent and batch loads can be serviced efficiently, e.g.
caffeine => memcached and a full misses to postgres. In that set up you can
still cache the search query as its own cache entry, but it does become
trickier about when to proactively invalidate it when the mappings change (and
if rarely changes you can often just invalidate the entire query cache). If you
want a full, in-memory replica then you don't need a cache as its a replication
strategy tied to an unbounded map. Caffeine does let you scan its contents
using the asMap view, but that is the current working set and seems error prone
for your use-case. A related but different concept is an entry having multiple
unique lookup keys (e.g. email, phone => user) where a possible solution is
shown in the
[IndexedCache|https://github.com/ben-manes/caffeine/tree/master/examples/indexable]
example.
> Upgrade from ehcache v2
> -----------------------
>
> Key: FC-327
> URL: https://issues.apache.org/jira/browse/FC-327
> Project: FORTRESS
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Shawn McKinney
> Priority: Major
> Fix For: 4.0.0
>
>
> Fortress core uses ehcache v2. It is getting long in tooth, has a number of
> CVE's, and needs to be replaced. Here we'll look at alternatives.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
