## Transaction Consistency (High)

### Trigger Signals

Start this detection when the following code characteristics appear:
- Multiple database write operations (insert/update/delete) in the same function without transaction wrapping
- Cross-service calls (HTTP/RPC/message queue) mixed with database write operations
- Cache operations (set/del/invalidate) mixed with database write operations
- Multi-level write operations in nested function calls

### Judgment Process

1. **Identify write operation set**: `Read` extracts all write operations within the function (direct write operations + indirectly triggered write operations through function calls), marking operation targets (database/cache/external services)
2. **Check transaction coverage**: `Read` confirms whether write operations are wrapped in a transaction:
   - Whether there is a transaction start (`beginTransaction`, `@Transactional`, `session.startTransaction`)
   - Whether transaction scope covers all write operations
   - Whether transaction scope is too large (includes unnecessary read operations, extending lock hold time)
3. **Check cross-service consistency**: For flows containing external calls, `Read` checks whether compensation mechanisms exist:
   - Saga/choreography pattern (local message table, outbox pattern)
   - Failure retry + rollback (cancel/compensate functions)
4. **Check cache consistency strategy**: `Read` confirms the update order between cache and database:
   - Whether there is a risk of reading stale cache due to "delete cache before write DB" ordering
   - Whether there is data inconsistency due to "write DB without deleting cache"

### Evidence Construction

After confirming a defect, the output must include:
- Write operation set (all write operations and their targets, with file:line number)
- Transaction coverage gap (which write operations are not protected by transactions)
- Cross-service/cache consistency risk (missing compensation mechanism or improper strategy)
- Business impact (consequences of partial commit, dirty data, cache-DB inconsistency)

### Exclusions

- Single-step write operations (no transaction needed)
- Already using saga/orchestration framework with clear compensation logic
- Eventual consistency scenarios with reconciliation/retry mechanism as fallback
