Closed hego-fdc closed 4 years ago
The first thing I'd try is to put:
DISABLE_OOB=ON
in a sqlnet.ora file on the machine where you are running your application. If this file is new to you, info on where to put it is in doc like https://cx-oracle.readthedocs.io/en/latest/user_guide/connection_handling.html#optional-oracle-configuration-files
The second thing I'd try is some other (non-PL/SQL statement) long running statement.
Wow, ok, you exactly got it right it seems: Disabling OOB prevents the dpiStmt_execute
function from hanging. While it does not cancel the DBMS_LOCK.SLEEP
function, it does cancel other long-running queries, which is what I need. Can you explain what might be going on here?
The OOB setting is just working around a network configuration which is inlining or dropping OOBs. When using 19c client & server, the correct setting will be automatically determined.
I don't know specifics about DBMS_LOCK.SLEEP
but I know that way, way back in the past there was an effort to improve the break flag checking in the PL/SQL layer, hence my suspicions when I saw your use. Feel free to log bugs with Oracle Support - but it's probably best to check a newer Oracle version first.
dpiConn_breakExecution
doesn't break DBMS_LOCK.SLEEP
on Windows.
See https://github.com/rsim/oracle-enhanced/issues/763#issuecomment-187744870
@kubo good reference.
To quote a bit more of the (old) support note that @yahonda gave:
With the DBMS_LOCK.SLEEP package, the sleep means that the session thread is not given any CPU time. Hence no check is made for break packets.
The issue does not reproduce with long running queries, as the session thread is given plenty of CPU time. This enables the checking for break packets.
This issue is specific to DBMS_LOCK.SLEEP and other blocking calls such as DBMS_PIPE.
@krismohan I suspect 18c's call timeout (dpiConn_setCallTimeout) is impacted the same?
It seems that 18c's call timeout (e.g. dpiConn_setCallTimeout) on OCIStmtExecute()
does break DBMS_LOCK.SLEEP
, as least with recent DB versions.
It appears this question has been answered so will close. Feel free to reopen if you have further questions, however!
The following program creates a long-running statement and in a separate thread cancels it. I would expect that the dpiStmt_execute function returns after the cancellation, but it never returns. When not spawning the thread, the function returns as expected.
I'm using the dpi.h from the master branch and I'm using driver version 11.2 both on the client and on the server side (I have also tested with other client driver versions, without any change). Compiler is gcc 8.3.0.