Re: DBMS Pipe problem

Nitin wrote:

<snipped>
> What I had observed is when we send a SIGUSR1 to the process it comes
> to sig_stop function and starts waiting at COMMIT WORK RELEASE step.
> Incase I am sending another SIGUSR1 then it goes ahead otherwise it
> continues waiting.
>
> Is there anyway by which we can solve this problem ?? Can we use
> signals to break out of DBMS Pipe receive ??

An Oracle connection handle is serialised. This means that you can only send a single request at a time and have to wait for it to be completed.

Reason: that connection is serviced by an Oracle shared or dedicated server process. This process is serialised. It does not multithread. It can only process a single client request a time. The only time it does "multithread" is to make use of PQ (Parallel Query) slave processes to assist in I/O related operations. But even then that is to complete a single request.. and only after that has been completed can the client send the next request. Thus you cannot close a DBMS_PIPE via an interrupt using the connection handle that is currently being used to service a DBMS_PIPE read.

Solution: the main processing thread must use a timeout on reading/accepting data from the DBMS_PIPE. When a timeout occurs, it need to check a global var to see if the process needs to terminate or not. When the SIGUSER1 interrupt handler is called, it simply sets the the global var and exits. When the DBMS_PIPE timeeout occurs, the process will detect that it needs to shutdown.

Shutdown response is thus a factor of the timeout period use when waiting for data on the DBMS_PIPE.

Also keep in mind that an interrupt should usually do *NO* work. An interrupt should basically just set a flag to inform the main process that processing status need to be changed. Doing work inside an interrupt is not a good idea.

--
Billy