A Spring self-check tests spring data and production contract using the source-kit contracts.
Review before answering
- Spring JdbcTemplate: bound values and visible database constraints
- Spring TransactionTemplate: roll back a failed multi-row change
- Spring transactional methods: call paths and rollback assumptions
- Spring task executors: capacity, rejection and lost context
- Spring cache keys: separate tenants and test the loader count
- Spring Boot Actuator health: public liveness without public diagnostics
- Spring Boot receipt API project: build, test and inspect the limits
- Spring task executors: reject work when every slot is occupied
- Spring outbox claims: allow recovery after a worker lease expires
- Outbox acknowledgements: require the current lease token
- Spring consumer deduplication: commit the event ID with the mutation
- At-least-once delivery: where Spring outbox retries can duplicate work
- Spring tenant command transaction: keep state, event and replay record together
- Spring POST idempotency keys: bind replay to tenant and command
- Spring JDBC versioned tenant update: inspect the affected row count
- Spring receipt outbox command: record intent without claiming delivery
- Spring command rollback test: inspect state after an injected failure
- Spring exercise: trace tenant command replay, denial and rollback
Check your reasoning
Answer every question, then read the explanations. This browser self-check is not a credential or a server-side code judge.
Common Mistakes
Distinguish a checked local fixture from a production guarantee. Container ownership, database atomicity and request authorization require separate evidence.