TierCache 2.0.0

TierCache 2.0.0 isolates Redis cache namespaces and hardens invalidation recovery, concurrent writes, resource ownership and Spring asynchronous cache retrieval.

Breaking change: coordinated migration from 1.x

Redis keyspace v2 separates data, tags, journals, channels, consumer groups and rebuild locks. Complete cache names are encoded so clearing one cache cannot delete another cache's data or control state.

Do not perform an ordinary rolling upgrade from 1.x. Drain and stop old readers/writers, start 2.0.0 with empty v2 namespaces, and allow for cold-cache load on the source. Legacy data is neither read nor migrated automatically. Rollback also requires a drained cutover and clean isolated cache storage.

Read the migration and rollback guide and all upgrade notes before deployment. Custom tagged-write transports and custom L1 providers may require the SPI capabilities described there. Enabled invalidation journals now require capacity of at least 65; the default remains 10000.

Correctness and recovery

• Foreground reads joining skipped refreshes no longer receive a false null.
• Losing tagged writes no longer warm L1, publish a losing value or replace tag indexes. Data and reverse indexes share an absolute expiration instant.
• Journal recovery performs bounded asynchronous I/O outside state monitors. Streams drains pending batches and requires a safe reset before acknowledging unreadable history.
• L1 freshness follows the retained value's lifetime. Atomic access refresh cannot resurrect an evicted entry.
• Owned lock/cache resources close safely across initialization and shutdown races.
• Managed Spring caches implement both asynchronous retrieval overloads; publication outcomes, JMX ownership and locale-independent metric labels are corrected.

Compatibility and dependencies

Java 17 remains the baseline. CI covers Java 17/21/25, Redis 6.2/7.4/8.x, Valkey, Spring Boot 3.5/4.1 consumers and Redis Sentinel. Redis Cluster remains unsupported by the built-in transport.

Micrometer is updated to 1.15.12 and the transport uses Netty BOM 4.2.17.Final. Signed release evidence includes resolved dependency inventories, SBOMs, vulnerability scan results and checksums for publication files. Scan the resolved dependency graph of your own application when overriding BOMs.

Operational limits

• The cache is eventually consistent. Sentinel's asynchronous replication can lose invalidations during failover and temporarily restore an older cached value; Pub/Sub and Streams cannot guarantee read-your-writes through such failures.
• In the tested Spring configuration, cold startup requires a reachable Redis/Sentinel journal connection.
• During Redis outages, misses can overload the source. Optional bounded stale retention improves availability at the cost of freshness; size TTLs and source concurrency to application requirements.

A six-instance Docker campaign on the same runtime code completed a 60-minute mixed-load run at 6000 RPS: 21.6 million requests, p99 187 ms and 47 errors (0.000218%). All 720 writes were acknowledged; no stale answers after the one-second allowance were found among 9.64 million freshness-checked responses. Failure scenarios covered Sentinel promotion/primary loss, partitions, journal truncation, Redis/source outages and API restart. These are measurements of one stand, not universal throughput or consistency guarantees. RSS grew by 22–30 MiB per JVM over that hour; the run does not establish a full memory plateau or prove the absence of leaks.

Maven Central

implementation("io.github.cramen:tiercache-spring-boot-starter:2.0.0")

All nine library/TCK modules use version 2.0.0. See the full changelog for details.

Release verification

• CI for the release commit: passed.
• Nightly gates on the identical candidate tree: passed, including PIT (core 83%, invalidation 78%; threshold 75%), native smoke, Sentinel, reproducible build and dependency checks.
• Final signed evidence: passed; Sigstore signature, GitHub attestation and all manifest hashes independently verified.
• All 49 publication files across nine modules were downloaded from public Maven Central and matched the final evidence SHA-256 values. The attached Central bundle contains these exact files with PGP signatures and checksums.