Re: dbms_pipe

Carlos wrote:
> Some considerations:
>
> Are you creating the pipe explicity (CREATE_PIPE)?

Yeah, and I'm setting the pipe size to various settings to see how Oracle behaves. It's currently set to about 200k.

>
> >>C. Once that reader dies, you can still put data in the pipe.
> Do you capture the return values of SEND_MESSAGE and EXCEPTIONs?

Yeah, I capture the values. And yes, indeed it tells me that something bad has happened. With send_message, it returns back that the pipe has timed out. With pack_message it tells me that there is no more room on the pipe. Actually, you need to pack_message before you send it. (And it appears that the 'packing area' and the 'pipe area' are the same place, which strikes me as odd.)

> If the
> reader 'dies' and the writer goes on SENDing, how is that the pipe
> doesn't reach the maxpipesize?
>

It does reach maxpipesize, and at that point, I can stop sending data. I'd like to stop sending data before that, but there's no way to check if the 'other end' of the pipe is down.

> Do you SELECT from V$DB_PIPES when the reader 'dies' to see what's
> going on? There can be 'automatic pipe cleanout' issues.

That table just tells me the name of the pipe, and it's size. It doesn't give me any other information. Are there other tables in regards to pipes I can poke around and look at? (By the way, how do you know about this table? There's nothing about it in the DBMS_PIPE oracle doc.)

Again, what I think is happening is that Oracle makes note of when a reader attaches to pipe. It makes note of it ONCE, and doesn't seem to care if the reader goes down or when it 're-attaches'.

DBMS_PIPE.purge does not work at all. Actually, I think it's an empty function, because when I give it a garbage value, it comes back as executing successfully.

>
> Hope this helps.
>

Sure is... as long as I can kick around some things it helps. Now, what I'm thinking is that Oracle probably has another internal table which associates the reader end of the pipe with a process id.

When the process id dies, that table never gets updated. So when the same program restarts with a different process id, Oracle doesn't send data.

Process id, I use losely here. It could be some 'internal oracle id', or some how a session id, or proc id. Because remember, the program must run a proc which then reads the pipe. So perhaps there is a session still running when I kill the program.

Don't know... any other helpful questions or ideas?

thanks.

-Godfrey T. Degamo
 gtdegamo_at_yahoo.com

> Regards from sunny Spain.
>
> Carlos.
Received on Fri Apr 08 2005 - 17:00:36 CDT