Java Programming Questions

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.

Primary key vs Unique constraint vs Foreign key

• Primary Key: Uniquely identifies rows, not null, usually clustered/indexed. Use case: id column for entity lookups. Performance: fast primary-key lookups; inserts/updates maintain index cost. JPA: @Id (often @GeneratedValue).

• Unique Constraint/Index: enforces uniqueness on column(s) but allows nulls (DB-dependent). Use case: email must be unique. Performance: supports fast equality lookups; adds overhead on writes. JPA: @Column(unique = true) or @UniqueConstraint on @Table, and @NaturalId in Hibernate.

• Foreign Key: enforces referential integrity between tables. Use case: order.customer_id references customers(id). Performance: adds checks on inserts/updates/deletes and may block cascading deletes; supports join optimizations when indexed. JPA: @ManyToOne with @JoinColumn; database-level FK is separate but generated by schema tools.

Trade-offs: more indexes = faster reads, slower writes. Use proper indexing and selectively enforce constraints where integrity matters.

Approach overview

1. Triage heap dump to identify leak source. 2) Reproduce locally with targeted load. 3) Remediate and add tests/CI checks.

Tools

• Capture: jmap (heap dump), jcmd GC.heap_info
• Analyze: Eclipse MAT, jhat, VisualVM
• Runtime: jcmd VM.native_memory, async-profiler

Investigation steps

• Open dump in MAT. Look at Dominator Tree and list org.example.cache.Cache$Node retained set.
• Inspect GC Roots and shortest reference chains to GC root to find why nodes are strongly reachable.
• Check incoming/outgoing references: static fields, ThreadLocal maps, live threads, listener lists.

Common patterns to check

• Static collections or caches without eviction
• ThreadLocal holding value per thread pool thread
• Unregistered listeners/callbacks or scheduled tasks
• Large object graph retained via single root (e.g., session map)

Reproduce locally

• Build a focused test that exercises caching behavior and runs under similar concurrency/sample data.
• Use stress test or unit test that runs until memory grows, capture periodic heap dumps.

Remediation

• Add eviction (LRU/TTL) or use Weak/SoftReferences where appropriate.
• Ensure listeners are removed on lifecycle stop; clear ThreadLocal in finally blocks; close scheduled tasks.
• Replace static caches with Cache implementations (Caffeine) with size/expire and metrics.

Prevention

• Add unit/integration memory tests (heap baseline after workload), leak-detector in CI (e.g., assert retained size below threshold), and CI job that runs short stress tests and compares heap usage.
• Instrument production with metrics (cache size, GC pause, native memory) and alerts.

This methodical pipeline ensures root cause discovery, safe remediation, and regression protection.

Requirements & constraints

• Read latency low; inventory updates frequent.

Denormalization approaches

• Duplicate columns: keep product, price, inventory_qty in a product_read model for fast reads.
• Materialized views: DB-side aggregated view refreshed incrementally or via CONCURRENT REFRESH.
• Update streams: CDC (Debezium) → message queue → product cache/store (e.g., Redis or read DB).

Change propagation

• Use CDC to emit ordered change events per product key into partitions preserving per-product ordering.
• Consumers apply updates idempotently; use sequence numbers or change timestamps.
• For high throughput, partition by product_id and use single-consumer per partition to preserve order.

Bounding staleness & reconciliation

• SLA: e.g., <1s eventual consistency. Provide read API flags: strong (read master) vs stale-allowed (read replica/cache).
• Store last_applied_lsn/offset per product; on divergence run reconcile job that compares source of truth and replays missed events.
• For conflicts, last-write-wins by LSN or merge strategy for merges.

Reliability

• Exactly-once processing: writer stores processed offset checkpoint atomically with update or use idempotent upserts with version numbers.
• Monitoring: lag metrics, missing events alerts, periodic full consistency checks.

This balances sub-ms read latency with bounded staleness and robust reconciliation when divergence occurs.

GET /users with pagination and X-Total-Count (Spring Boot)

Controller signature:

@GetMapping("/users")
public ResponseEntity<List<UserDto>> list(
  @RequestParam(defaultValue = "0") int page,
  @RequestParam(defaultValue = "20") int size) {
  Page<User> p = userService.findAll(PageRequest.of(page, size));
  HttpHeaders h = new HttpHeaders();
  h.add("X-Total-Count", Long.toString(p.getTotalElements()));
  return new ResponseEntity<>(p.getContent().stream().map(...).collect(toList()), h, OK);
}

Service: use Spring Data Pageable (userRepository.findAll(Pageable)) or manual SQL with LIMIT/OFFSET and a separate COUNT(*) query. Repository: Spring Data JPA returning Page<User>.

Testing: unit-test controller mapping and header presence using MockMvc; integration test with Testcontainers asserting pagination, boundary pages (page beyond last returns empty list and total count), invalid params (negative values) return 400, and correctness of X-Total-Count matching DB count.