Oracle leaves unix process still running after concurrent request has been cancelled.

[Mary Hart]

User terminates concurrent request properly inside 11i applications but Unix process continues to run and consume high percentage of CPU. Why does Oracle leave these behind and is there anyway to have these automatically killed? We discover this when we look at top and find processes that have been running for an extended period of time and taking very high CPU. When tracing the PID back (which is extremely time consuming) within Oracle, we find that the job had been cancelled. Any ideas?
My versions are:
Database 8.17
Oracle applications 11.5.8
HPUX 11.11

[James A. Donovan]

This is a known problem...

http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=105138.1

There exists a problem that some customers face with regards to terminating Concurrent Requests: Under some circumstances, the front end process is killed, but the shadow process continues on for quite a while (still performing operations on the database). While relatively rare, this may have severe consequences if the conflict resolution manager thinks that the terminated program has exited and allows an incompatible program to run.

There is a two-part solution to this problem: 1) Set the value of sqlnet.expire_time to 1 in sqlnet.ora. This tells the shadow process to check to make sure that the front end process is still alive every minute or so. Oracle recommends the value of one minute (the minimum), but it can be set higher.

2) Set the value of the environment variable FDCPTRW to sqlnet.expire_time plus one (e.g. if sqlnet.expire_time = 1, then set FDCPTRW to 2). This will cause the concurrent manager to consider the concurrent request to be alive for at least FDCPTRW minutes after the front-end process was killed, thereby preventing any conflicts from occurring. The use of this feature will require installing the patch 607472 for Release 10.7. This feature is ready to use in Releases 11.0 and later.

3) Make sure that the PMON method is set to LOCK, because if it is set to RDBMS, the internal concurrent manager queries against v$process to retrieve the session id (the one that started the request) and the operating system process id. The reason it needs to query against both columns and not just the OS pid is because if there are concurrent managers running on two different clients against the same RDBMS then two requests could have the same OS pid.

[Mary Hart]

Thank you for the information. I have forwarded it to my DBA. This is certainly more information than we have been able to acquire from other sources (including Oracle). As soon as I know if the solution works for us, I will post a reply.