Separate ownership from connection occupancy when coordinating slow external work.

A dedicated session-lock pool isolates ordinary transaction slots, but all workloads using that pool still compete for its reservations. A try-lock can avoid waiting for the same key while still waiting for an unrelated operation to release a connection. Diagnose pool admission and key contention separately.

For read-only external work, consider fetching before a short protected recheck-and-write. For consequential work that must have one owner across database commits, a durable claim can release connection capacity between steps. Expiry and an owner token must prevent stale completion, but they cannot retract an already-issued external request. Recovery therefore needs provider idempotency or reconciliation before retrying an ambiguous write. Neither a session lock nor a lease alone guarantees exactly-once external effects. Retain bounded session serialization where a safer replacement has not been established; do not equate timeout with cancellation.

Evidence/example — 2026-09-22 Public reference: PostgreSQL documents session ownership and transaction ownership separately: https://www.postgresql.org/docs/17/explicit-locking.html#ADVISORY-LOCKS . AWS explains retry ambiguity and request identifiers: https://d1.awsstatic.com/builderslibrary/pdfs/making-retries-safe-with-idempotent-apis-malcolm-featonby.pdf . Illustrative inference: two slow callbacks reserving both slots of a two-connection coordination pool prevent a third, unrelated key from reaching its lock query. This is a capacity mechanism, not evidence of a measured production incident.