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. (1) Drop {{SecondLevelCacheStatistics}}
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. (2) Drop "cache-related stats" from {{QueryStatistics}} and {{ NaturalId NaturalIdCacheStatistics}}
Currently both {{QueryStatistics}} and {{NaturalIdCacheStatistics}} expose caching-related stats in addition to their specific stats. That is an inconsistency. Either we should drop these from {{QueryStatistics}} and {{NaturalIdCacheStatistics}}, or add the same to {{EntityStatistics}} and {{CollectionStatistic}}.
Here, there all caching-specific stats would be a statistic object specifically for describing exposed through the stats related dedicated {{SecondLevelCacheStatistics}} (which I propose we rename to a particular caching region {{CacheRegionStatistics}}) . Another aspects to the inconsistency here is that currently {{SecondLevelCacheStatistics}} does not cover query nor natural-id caching - those are only available from {{QueryStatistics}} and {{NaturalIdCacheStatistics}}
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 h2.(3) Combination - expose both ways
Here , but I we ' m just not sure how important it is to users to be able to locate d expose caching stats specific to an entity from all of {{EntityStatistics}} , natural-id {{CollectionStatistic}} , collection. I think that since the user chooses to configure what data is kept {{QueryStatistics}} and {{NaturalIdCacheStatistics}} in which regions that this is actually not such a big deal addition to also having them available from {{SecondLevelCacheStatistics}} ({{CacheRegionStatistics}}) . However The values exposed from {{EntityStatistics}} , if they do end {{CollectionStatistic}}, {{QueryStatistics}} and {{NaturalIdCacheStatistics}} would be specific to those things where as the values exposed from {{SecondLevelCacheStatistics}} would be a "roll up caching multiple types " of data in the same individual things stored in that particular region then they'd really need the per .
- type - of - data stats - It is important to be able note that any of these represent a change to tune caching the API and SPI for stats . (3) gives the greatest compatibility. (1) is pretty compatible except for custom stats implementors. (2) can be done in a pretty compatible manner with deprecations.
Coupled with this discussion is |
|