Overview
Covers Caffeine, local caches, distributed Cache, shared CAS, TTL, and idempotency uniformly. Confirm the maintenance line with ddd4j-javalin-version-selection first, then read the current branch source.
When to Use
- Selecting between Caffeine local caches and a distributed Cache with shared CAS for a ddd4j-javalin service on 6.7.x, 7.1.x, or 7.2.x.
- Deciding the idempotency backing: Caffeine explicitly as a single-instance/development fallback, shared CAS for multi-instance production.
- Configuring TTL, invalidation, and concurrency behavior for local providers, and lock contention/retry behavior for the distributed provider.
- Registering cache providers as lifecycle participants with explicit owners, readiness contribution where required, and idempotent close.
- Validating production behavior: real CAS contention, retries, and TTL re-acquisition against the shared backend — not a local fake.
When NOT to Use
Do not use this skill when:
- The HTTP idempotency filter and replay responses on routes are the question — use
ddd4j-javalin-webinstead. Install:npx skills add full-stack-skills/ddd4j-skills --skill ddd4j-javalin-web. - Lifecycle participant mechanics (ordering, rollback, hooks) are the question — use
ddd4j-javalin-runtimeinstead. Install:npx skills add full-stack-skills/ddd4j-skills --skill ddd4j-javalin-runtime. - The framework-agnostic
CacheSPI contract is the question — useddd4j-coreinstead. Install:npx skills add full-stack-skills/ddd4j-skills --skill ddd4j-core. - A cross-capability review or release gate is needed — use
ddd4j-javalin-production-hardeninginstead. Install:npx skills add full-stack-skills/ddd4j-skills --skill ddd4j-javalin-production-hardening. - Spring Boot or Quarkus cache wiring is the question — use
ddd4j-boot-cacheorddd4j-quarkus-cacheinstead, for example Install:npx skills add full-stack-skills/ddd4j-skills --skill ddd4j-boot-cache. Spring Cloud cache composition:ddd4j-cloud-architecture. - The project tunes plain Caffeine or Redis without ddd4j — do not use this skill; use
java-skillsinstead, since the ddd4jCacheSPI and shared-CAS contract do not exist there.
Trigger Keywords
English: local cache, distributed cache, CAS, TTL, idempotency backend, Caffeine, cache lifecycle
Chinese: local cache, distributed cache, CAS, TTL, idempotent backend, Caffeine, cache lifecycle
Core Scope
Caffeine, local caches, distributed Cache, shared CAS, TTL, idempotency.
Core Rules
- 6.7.x, 7.1.x, and 7.2.x each keep their own Javalin/JDK/Maven/POM contract.
- Javalin 6 versus 7 API differences are aligned by behavior, not copied mechanically.
- Report configuration, startup, HTTP, containers, CI, and publishing in layers.
- Context/Subject/resources are cleaned on success, exception, and async terminal states.
- Production dependencies need real readiness, shared CAS, explicit CORS, and idempotent close.
Capability Boundaries
✅ Strong At
- Implementation choice for caching and Javalin adaptation.
- Lifecycle, configuration, and behavior boundaries.
- Differences across the three maintenance lines.
⚠️ Needs Input
- Target branch, POM, and Javalin version.
- Business behavior, dependencies, and deployment mode.
- Current source/test/CI evidence.
❌ Out of Scope
- Copying Javalin 6 code directly to 7.
- Substituting smoke tests for real behavior.
- Unauthorized releases or production changes.
Workflow
Step 1: Confirm the source of truth
Fix the maintenance line with ddd4j-javalin-version-selection, then locate the cache module and the web idempotency tests in the current checkout.
Step 2: Select the provider
Use Caffeine only for single-instance or development deployments, with explicit configuration and a documented fallback status. Use a distributed cache with shared CAS wherever multi-instance production idempotency is required.
Step 3: Wire the lifecycle
Register cache providers as lifecycle participants with explicit owners and idempotent close. Confirm readiness reflects cache backend availability where the deployment contract requires it.
Step 4: Test against the real backend
Verify TTL, invalidate, and concurrency for local providers. For the distributed provider, verify real CAS contention, retries, and TTL re-acquisition against the shared backend — a local fake that never contends proves nothing.
Step 5: Report the cache state
Produce a single report: provider choices with configuration keys, lifecycle registration and shutdown order, tests executed with evidence state per tier, and risks with proposed fixes and missing inputs.
Gotchas
- Caffeine-backed idempotency is a single-instance fallback only; multi-instance production needs shared CAS — two replicas each holding their own key set deduplicate nothing across instances.
- CAS correctness must be proven against the real shared backend; a local fake that never contends cannot expose lost locks or TTL re-acquisition failures.
JavalinLifecycleParticipantshutdown runs in reverse registration order; a cache registered early must close last, and close must be idempotent.- Readiness should reflect cache backend availability where required — a silent READY hides a degraded CAS until the first duplicate write slips through.
- TTL re-acquisition failure (the lock is lost mid-operation) needs an explicit path; silently proceeding is a duplicate waiting to happen.
- The maintenance lines do not change Caffeine semantics, but the per-line POM/JDK contract still governs the module — do not copy 7.2.x-only syntax into older lines.
Output and Exceptions
When input is missing, output "missing: target line/implementation/configuration; how to provide: supply the POM and acceptance behavior", and continue safe read-only checks.
Deep Reference
Privacy and Security
Never output tokens, cookies, OIDC secrets, or database or private repository credentials.
This skill does not access, collect, store, or transmit any user data, credentials, or keys; cache examples use only desensitized fictional data.
Quick Start
- "Use
$ddd4j-javalin-cacheto analyze the implementation and configuration my current project should adopt." - "Use
$ddd4j-javalin-cacheto review existing usage against the current source." - "Use
$ddd4j-javalin-cacheto return an implementation choice, evidence state, and remaining risk."
Audience and Customization
- Developers: provide the target maintenance line, POM, capabilities, and acceptance behavior.
- Architects: specify a read-only boundary review, compatibility, or migration target.
- Testers / release engineers: specify the required evidence levels; do not auto-expand to release or production operations.
Customize the target framework, allowed implementations, excluded modules, compatibility requirements, and output evidence level. When input is insufficient, give a tentative verdict first, then list "missing: specific item; how to provide: required path or configuration".
FAQ
- Are skills organized by Maven artifact? No — by the user-facing capability domain.
- Can I copy another maintenance line directly? No — verify the version and source first.
- Does a class existing in source prove the capability works? No — registration and behavior evidence are also required.
- How do I report tests that did not run? Mark
NOT RUNorBLOCKED. - Can the skill commit or release automatically? Only after explicit user authorization.
- What if the implementation is missing? Describe the missing module or evidence; do not invent APIs.