Summary
Running a .sql script from a SQL Worksheet that spools output to a local .log file and issues ALTER SYSTEM KILL SESSION ... IMMEDIATE against a session that cannot be killed synchronously (Oracle returns ORA-00031: session marked for kill) causes the worksheet's own connection to drop immediately afterwards with DBTS-05102: The connection session was terminated — even though the killed session is a different database session. Because the script never reaches its spool off statement, the local .log file is left with an open OS-level file handle and cannot be opened, renamed, or deleted afterwards ("used by another process") until the VS Code window is reloaded.
Environment
- Extension: Oracle SQL Developer for VS Code 26.2.1
- VS Code: 1.135.0 (commit 08d4889f9ec4a1685d257b9b95de036c8e1ce1e5), x64
- OS: Windows 11 Enterprise 10.0.26200
- Oracle Database: 19.21.0.0.0 (19c), CDB/PDB architecture
- Connection type: saved connection profile (Basic/TNS)
- Instance state at the time: under sustained latch: shared pool contention caused by an unrelated application defect (hundreds of millions of hard-parse/execute cycles of the same shared cursor)
What happens
- A .sql script is run in a SQL Worksheet. It does, in order:
- spool ".log"
- a diagnostic SELECT ... FROM gv$session
- ALTER SYSTEM KILL SESSION ',<serial#>,@' IMMEDIATE targeting a session that is 100% CPU-bound in a tight server-side PL/SQL loop (no round-trips to its client, so the kill cannot complete synchronously)
- a follow-up verification SELECT
- spool off
- Oracle correctly returns ORA-00031: session marked for kill for the ALTER SYSTEM KILL SESSION statement — expected, since the target session isn't at an interruptible point yet.
- Immediately after that, the worksheet's own connection drops: DBTS-05102: The connection session was terminated. Script execution stops right there.
- The remaining statements (verification SELECT and spool off) never run, because the connection is gone.
Consequence: locked spool/log file
Because spool off never executes, the .log file is left with an open handle. Any subsequent attempt to open/rename/delete it fails with a Windows sharing-violation error. None of the externally-visible processes (sql.exe, java.exe helper processes) appear to hold the handle, which suggests it's held internally by an extension host process rather than an external SQLcl/Java child process.
This looks like the same underlying class of bug already reported in #29 (extension backend not releasing a Windows file handle around an abrupt state transition) — there it was credentials.sso during a connection-save rename; here it's the spool .log during an abrupt disconnect.
How to reproduce
- Have an Oracle session on the target instance that is 100% CPU-bound in a tight, non-interruptible server-side loop (any PL/SQL block that loops without returning control to its client) — the precondition for ALTER SYSTEM KILL SESSION to be unable to complete synchronously.
- In a VS Code SQL Worksheet (via this extension), run a script that spools to a file, then issues ALTER SYSTEM KILL SESSION ',<serial#>,@' IMMEDIATE against that session, followed by more statements and spool off.
- Observe ORA-00031, then DBTS-05102 and the worksheet disconnecting before the rest of the script (including spool off) runs.
- Try to open/rename/delete the .log file — it's locked.
Workaround found
- Developer: Reload Window (Ctrl+Shift+P) restarts the extension host and releases the file handle, without needing to fully close and relaunch VS Code.
- Verifying independently (fresh connection) that the target session's SID/SERIAL# no longer exists in gv$session confirms the KILL SESSION did succeed on the database side despite the client-side disconnect — the disconnect and the locked file appear to be purely client-side artifacts, unrelated to the actual outcome in the database.
- As a practical mitigation, spooling each script run to a uniquely-named/timestamped log file avoids being blocked by a previously locked file on retry.
Suspected contributing factor
The instance was under heavy latch: shared pool contention at the time (unrelated application defect). That's an instance-wide shared resource, so it's plausible the worksheet's own session experienced elevated latency at the same moment, compounding with the connection-drop behavior already reported in #25 to trigger the disconnect right after the KILL command.
Related issues
Summary
Running a .sql script from a SQL Worksheet that spools output to a local .log file and issues ALTER SYSTEM KILL SESSION ... IMMEDIATE against a session that cannot be killed synchronously (Oracle returns ORA-00031: session marked for kill) causes the worksheet's own connection to drop immediately afterwards with DBTS-05102: The connection session was terminated — even though the killed session is a different database session. Because the script never reaches its spool off statement, the local .log file is left with an open OS-level file handle and cannot be opened, renamed, or deleted afterwards ("used by another process") until the VS Code window is reloaded.
Environment
What happens
Consequence: locked spool/log file
Because spool off never executes, the .log file is left with an open handle. Any subsequent attempt to open/rename/delete it fails with a Windows sharing-violation error. None of the externally-visible processes (sql.exe, java.exe helper processes) appear to hold the handle, which suggests it's held internally by an extension host process rather than an external SQLcl/Java child process.
This looks like the same underlying class of bug already reported in #29 (extension backend not releasing a Windows file handle around an abrupt state transition) — there it was credentials.sso during a connection-save rename; here it's the spool .log during an abrupt disconnect.
How to reproduce
Workaround found
Suspected contributing factor
The instance was under heavy latch: shared pool contention at the time (unrelated application defect). That's an instance-wide shared resource, so it's plausible the worksheet's own session experienced elevated latency at the same moment, compounding with the connection-drop behavior already reported in #25 to trigger the disconnect right after the KILL command.
Related issues