Hibernate ORM pagination with PostgreSQL: ensuring idempotent retries for offset-based queries

Goal: guarantee that a transient failure during a paginated Hibernate query does not cause duplicate or missing rows when the request is retried with the same offset and limit.

Constraint: Hibernate translates setFirstResult() and setMaxResults() to database‑specific LIMIT/OFFSET clauses, which rely on the current ordering of rows. If the underlying data changes between the original attempt and the retry, the offset may point to a different logical page, leading to duplication or gaps.

Uncertainty: whether the default READ COMMITTED isolation level (or a stricter level) provides a stable snapshot for the duration of a retry, or if the application must adopt keyset pagination, entity version checks, or explicit transaction boundaries to achieve idempotent behavior.

Questions: Does Hibernate’s pagination combined with a repeatable‑read transaction guarantee the same result set on retry? If not, what minimal changes (e.g., adding a deterministic sort key or using seek‑method pagination) are required to make retries idempotent without altering the overall query semantics?