Oracle JDBC Thin Driver ↔ Database Resource Manager: Cancellation and Timeout Interoperability

Short answer

There is no documented precedence rule between a JDBC cancel()/setQueryTimeout break and a Resource Manager MAX_EST_EXEC_TIME kill. They are independent mechanisms that act on the same session, and the server processes whichever signal it handles first. In practice the JDBC break usually arrives first — it is a single out-of-band network message — while Resource Manager enforcement happens on a periodic evaluation cycle (roughly 1–3 seconds in 19c/21c, up to 60 seconds in pre-12c releases). That is a timing artifact, not a guarantee you should design around.

On the second question: lock release is not deferred to a Resource Manager cleanup cycle. Whichever mechanism terminates the session, the server performs an implicit rollback of the active transaction and releases its row and table locks as part of termination processing. What is deferred is the disappearance of the row from V$SESSION: the session shows STATUS='KILLED' until PMON's periodic cleanup runs (a few seconds in current releases). That behavior is identical regardless of which side initiated the kill.

Why the two paths are independent

The JDBC Thin driver implements cancel() (and the timer behind setQueryTimeout) by sending an out-of-band break over a separate TCP connection, handled by the server's network layer. Resource Manager limits are enforced by background processes that periodically scan consumer-group state. Neither path checks whether the other has already fired; the first one to reach the session's execution context wins, and the second becomes a no-op on an already-dying session.

One asymmetry matters: MAX_EST_EXEC_TIME is evaluated against the optimizer's estimated execution time, not elapsed wall-clock time. A bad cardinality estimate can kill a query that would have finished in seconds, and some operations (DDL, PL/SQL blocks, certain parallel executions) may not get an estimate at all and bypass the limit. setQueryTimeout, by contrast, measures actual elapsed time on the client — and can itself be delayed by client-side GC pauses or a stalled network.

What this means for your design

• Treat the two timeouts as redundant backstops, not a hierarchy. If the JDBC break is lost (firewall dropping the OOB connection, network partition), the Resource Manager limit is your safety net — and vice versa.
• Do not assume lock release waits for anything. If you observe blocking after a timeout, the more likely cause is that the session was never actually terminated (lost break, no applicable RM estimate), not that cleanup is pending. Check V$SESSION.STATUS and BLOCKING_SESSION.
• Remember that connection pools (UCP, WebLogic) add their own timeout and leak-detection layers that may fire before either Oracle mechanism, complicating diagnosis.

Verifying which mechanism fired

To confirm behavior on your exact version, run a controlled test: set MAX_EST_EXEC_TIME to 10 seconds and setQueryTimeout to 5, run a long query, then repeat with the values reversed. Correlate the results with:

-- Session state transitions and lock holding
SELECT sid, status, blocking_session, last_call_et FROM v$session WHERE ...;

-- Resource Manager view of the session (19c+)
SELECT sid, current_consumer_group, current_undo_consumption
FROM v$rsrc_session_info WHERE ...;

The alert log distinguishes the two paths ("Resource Manager: terminating session" versus a received break), and a SQL trace (event 10046) shows the corresponding server-side stack if you need definitive proof. On 19c and later, DBA_HIST_RESOURCE_LIMIT and V$RSRC_SESSION_INFO help post-mortem correlation; on older releases you rely on the alert log and trace files.

Caveats

This behavior is version-sensitive — Resource Manager evaluation intervals changed significantly between pre-12c and 19c+ — and the exact interaction is not formally documented by Oracle, so the precedence observations above reflect well-established behavior rather than a contractual guarantee. Verify on your target release before relying on either mechanism alone.