Cache observability shipped in a series of incremental additions and reaches its final shape in this sprint: a navigable tree that exposes the full cache hierarchy from a single root table. The structure mirrors the classloader and schema catalog trees — operators start at the root virtual table and drill into any cache to see its configuration, live statistics, and individual entries.
Root registry and statistics
- Unified root table. The
cache.cachesvirtual table lists every cache registered on the server with its type, maximum size, TTL configuration, and current entry count. - Hit/miss/eviction counters. Each root row carries cumulative hit, miss, and eviction counts since server start, readable without a JMX connection or log parsing.
- Per-entry drill-down. Drilling into a cache row returns its current contents — keys, values, and expiry timestamps — as a virtual child table. Large caches stream entries rather than materialising the full set.
Per-user and JDBC subtrees
- 21 per-user inner caches. A declarative binding registry exposes per-user caches as child nodes under their parent cache, with the same statistics columns as top-level caches.
- JDBCServer subtree. Caches maintained by the JDBC server — schema metadata, prepared-statement plans, per-database type maps — appear as a named subtree alongside application-level caches.
- Metadata-per-user flag. A
metadata_per_userJVM property switches schema metadata caches from the default shared mode to per-user isolation for deployments where schema visibility must not cross tenant boundaries.
The tree is read-only and computed on every query against the virtual tables; no background thread maintains a snapshot. A single SQL query against the root table identifies caches with anomalous miss rates; drilling into those caches shows which keys are absent — without leaving the platform's SQL interface.