The goal here is to align stats with changes in caching SPI and to address some inconsistencies in its API/SPI. Some potential designs...
h2. No separately exposed cache-specific statistics. (1) Drop {{SecondLevelCacheStatistics}} Instead, in In this approach, caching-related statistics are actually exposed on the thing being cached. For example, caching-related stats for an entity would be expose on {{EntityStatistics}}, etc.
This has the drawbacks that: # There is no over-arching view of the statistics for a given region (not convinced this is so bad, see comments) # Stats related to entity persistence-related events and caching-related events are modeled together even though there are distinct concepts.
E.g
{code} interface Statistics ... { ... EntityStatistics getEntityStatistics(String entityName); }
interface EntityStatistics ... { // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // persistence-related stats...
long getInsertCount(); long getUpdateCount(); ...
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // caching-related stats
long getPutCount(); long getHitCount(); ... } {code}
h2. Caching (2) Drop "cache -related stats are exposed per-region " from {{QueryStatistics}} and {{NaturalId
Here, there would be a statistic object specifically for describing the stats related to a particular caching region.
The main "drawback" here is that we would not expose caching related stats specific to entity, collection, natural-id - it would be region-wide. E.g.
{code} interface Statistics ... { ... EntityStatistics getEntityStatistics(String entityName); CacheRegionStatistics getCacheRegionStatistics(String regionName); }
interface EntityStatistics ... { // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // persistence-related stats...
long getInsertCount(); long getUpdateCount(); ... }
interface CacheRegionStatistics ... { long getPutCount(); long getHitCount(); ... } {code}
The second approach feels cleaner, but I'm just not sure how important it is to users to be able to locate caching stats specific to an entity, natural-id, collection. I think that since the user chooses to configure what data is kept in which regions that this is actually not such a big deal. However, if they do end up caching multiple types of data in the same region then they'd really need the per-type-of-data stats to be able to tune caching. |
|