Java Programming Questions

Requirements & constraints

• Strong consistency: updates visible immediately to subsequent reads across instances.
• Java/Spring Boot, relational DB, multi-instance.

Architecture recommendation

• Distributed cache (Redis) as single source for cached profiles to ensure coherence across instances.
• Use cache-aside pattern with atomic invalidation: write to DB inside tx, then invalidate or update cache atomically.

Invalidation/eviction strategy

• On read: try Redis; on miss, read DB and write-through to Redis with short TTL.
• On update: within DB transaction, update row, then publish a cache invalidation message (or update cache) after commit.

Atomic invalidation across instances

• Use DB transaction + outbox pattern: write update and an outbox row in same DB tx. A reliable publisher reads outbox and publishes an invalidation event to Redis pub/sub or a message broker.
• Consumers (app instances) subscribe and evict/update local caches upon event.

Multi-instance coherence

• Central Redis avoids split-brain; pub/sub ensures near-real-time invalidation.
• To avoid race (read-after-update) use read-after-write: client that performs update should update cache synchronously after commit (or include new value in response) so immediate reads see latest.

Trade-offs

• Distributed cache adds network latency but guarantees coherence; adds complexity (outbox, pub/sub). TTLs and eviction needed to bound memory.

Key components

• Pool manager maintaining idle and in-use sets.
• Acquisition algorithm: try take from idle queue; if empty and pool < max, open new connection; else wait with timeout and backpressure.
• Max pool size and wait policy: configurable max, exponential backoff or immediate failure (SQLTransientConnectionException) after timeout.

Validation & eviction

• Health-check on borrow (light validation query) or async validation for idle.
• Eviction thread scans idle connections, closes stale/broken ones after configured idleTimeout.

Leak detection

• Track borrow stack trace and timestamp; if held beyond leakThreshold, log warning and optionally close. Implement weak-reference based leak cleanup: schedule forced reclaim after grace period.

Thundering herd avoidance

• Use fairness queue with limited waiters; on exhaustion, requesters wait on Condition and wake a bounded number at a time. Use exponential backoff and circuit-breaker to reject fast failures.

Metrics

• Expose active_count, idle_count, wait_count, wait_time_ms, connection_create_rate, validation_failures, leak_warnings.

Implementation notes

• Use ConcurrentLinkedQueue for idle, AtomicInteger for size, ReentrantLock+Condition for waiters. Keep connection creation bounded to avoid resource storms.

Explain propagation behaviors (brief)

• REQUIRED: join existing transaction or start new if none. Common default.
• REQUIRES_NEW: always suspend outer tx and start a fresh one.
• MANDATORY: must run inside an existing transaction; throws if none.

Recommendation for funds transfer
Use REQUIRED for the service method that performs debit and credit so both operations run in one transaction and either commit or rollback together. Do NOT use REQUIRES_NEW for sub-operations (debit or credit) because that would commit independently and break atomicity.

Isolation level to avoid lost updates
Choose at least REPEATABLE READ (or SERIALIZABLE for strictest) depending on DB. To avoid lost updates, REPEATABLE READ plus explicit locking is often enough.

Optimistic vs Pessimistic locking in JPA

• Optimistic: add @Version column and use @Version on entity; JPA throws OptimisticLockException if concurrent update detected. Good when conflicts rare.

Example:

@Entity
class Account { @Id Long id; @Version Long version; BigDecimal balance; }

• Pessimistic: use EntityManager.find(..., LockModeType.PESSIMISTIC_WRITE) or repository.findById(..., LockModeType.PESSIMISTIC_WRITE) to acquire DB row lock. Use when high contention.

Use optimistic locking first for performance; if frequent concurrent transfers on same accounts, use pessimistic locking inside REQUIRED transaction to serialize updates.

synchronized vs volatile vs AtomicInteger

• synchronized: provides mutual exclusion and memory visibility. Guarantees atomicity for a block/method and that entering a synchronized block sees prior writes. Use when multiple operations must be atomic (e.g., check-then-act).
  Example: synchronizing updates to a List or performing composite updates on multiple fields.

• volatile: guarantees visibility and ordering for single reads/writes of a variable but not atomicity for compound ops. Use for flags or state switches.
  Example: a boolean shutdown flag read by multiple threads.

• AtomicInteger (java.util.concurrent.atomic): provides atomic operations (get, incrementAndGet, compareAndSet) and weaker locking overhead. Guarantees atomicity for its methods and volatile-like visibility.
  Example: high-throughput counters, sequence generators, or non-blocking algorithms.

Choose synchronized for compound critical sections, volatile for simple visibility, AtomicInteger for lock-free numeric updates.

Immediate mitigations

• Return to safe state: deploy previous release or disable offending feature via feature flag.
• Short-term traffic controls: scale replicas, apply rate-limits, route traffic to healthy zones.
• DB-level throttling: increase connection pool timeouts, reduce query concurrency, or apply statement_timeout.

Triage & root-cause steps

• Verify traces and identify slow SQL text and plan (capture full SQL with bind params).
• Run EXPLAIN (ANALYZE, BUFFERS) on production-like data to confirm sequential scan.
• Check recent changes: code, query text, ORMs, new indexes dropped, schema changes, pg_stat_statements.
• Inspect planner inputs: table statistics, recent VACUUM/ANALYZE, parameter changes (work_mem) or config flags.
• Reproduce with captured params on staging.

Safe rollback / hotfix

• If query change is in code: rollback deploy atomically.
• If stats or plan issue: run ANALYZE or CREATE necessary index; use CONCURRENTLY to avoid locks.
• Use partial rollout (canary) after fix.
• Ensure rollback plan tested and DB migrations reversible.

Postmortem outline

• Timeline, impact, root cause, detection method.
• Actionable items: automated detection alerts for query plan regressions, add tests for critical queries, require plan checks in deployment, schedule periodic ANALYZE, CI that runs EXPLAIN on sample datasets, runbooks for rollback.
• Owners, deadlines, verification steps and metrics to measure recurrence (99th latency, query duration percentiles).