[
https://issues.apache.org/jira/browse/FC-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18060078#comment-18060078
]
Ben Manes edited comment on FC-327 at 2/21/26 7:28 PM:
-------------------------------------------------------
Thanks [~smckinney],
The
[documentation|https://www.ehcache.org/documentation/2.7/apis/search.html#standalone-ehcache-without-bigmemory]
says that on-heap caches (no commercial features) uses an O( n ) scan of the
cached contents. It also says earlier that indexes are only built when entries
are added to the cache. My understanding is that this is then meant for a data
grid scenario where the index is fully materialized and updated cluster-wide
due to a full data load and the key-value cache acts as a fast, transparent
lookup on top of the source database. That only works in a distributed cluster
(Terracotta) or a single-server setup (BigMemory). The entire search index is
kept in-memory, the cache values are evictable, and there is the typical data
inconsistency concerns between the data structures.
However, if you are using this in a non-commercial fashion then there is no
full index. In this case the cache contents are scanned, which means it is an
_*incomplete* partial result_ as it only represents the current working set. If
the cache evicts a mapping then the search will not return the entry, even if
it exists within your database. To use this safely then it is not a cache but a
replica.
Does this match your experience? If so, then do you actually want or properly
handle cases when the cache evicts and the search returns partial results?
It appears to me that this may not be a good fit for a cache and instead an
unbounded map using warm replication would be a reasonable alternative. The
query could be a DSL to the full iteration, or could use something akin to the
[cqengine-next|https://github.com/MSaifAsif/cqengine-next] indexes, or use H2
for a complete in-memory & disk solution.
was (Author: ben.manes):
Thanks [~smckinney],
The
[documentation|https://www.ehcache.org/documentation/2.7/apis/search.html#standalone-ehcache-without-bigmemory]
says that on-heap caches (no commercial features) uses an {{O(n)}} scan of the
cached contents. It also says earlier that indexes are only built when entries
are added to the cache. My understanding is that this is then meant for a data
grid scenario where the index is fully materialized and updated cluster-wide
due to a full data load and the key-value cache acts as a fast, transparent
lookup on top of the source database. That only works in a distributed cluster
(Terracotta) or a single-server setup (BigMemory). The entire search index is
kept in-memory, the cache values are evictable, and there is the typical data
inconsistency concerns between the data structures.
However, if you are using this in a non-commercial fashion then there is no
full index. In this case the cache contents are scanned, which means it is an
_*incomplete* partial result_ as it only represents the current working set. If
the cache evicts a mapping then the search will not return the entry, even if
it exists within your database. To use this safely then it is not a cache but a
replica.
Does this match your experience? If so, then do you actually want or properly
handle cases when the cache evicts and the search returns partial results?
It appears to me that this may not be a good fit for a cache and instead an
unbounded map using warm replication would be a reasonable alternative. The
query could be a DSL to the full iteration, or could use something akin to the
[cqengine-next|https://github.com/MSaifAsif/cqengine-next] indexes, or use H2
for a complete in-memory & disk solution.
> 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]
