Re: get the sid,serial# of my connection?

On Dec 29, 2:02 pm, m..._at_pixar.com wrote:
> Mark D Powell <Mark.Pow..._at_eds.com> wrote:
>
> > Why not have the routine issue the kill via execute immediate rather
> > than have to cut and paste?
>
> Ah, I should have explained in more detail what I'm trying to do...
> I have an application server I've written, that basically is an
> infinite loop:
>
> initialize connections
> loop forever:
>    receive XML-RPC request
>    send request to db
>    send XML-RPC response
>
> I have some connection failure detection and recovery code
> in the loop, and I want to exercise that code, so I want to
> cause the connection to randomly fail outside of the control
> of the app server.  That's also why I'm looking for other ways
> to break the connection, in order to test all the applicable
> failure modes.
>
> thanks!
> Mark
>
> --
> Mark Harrison
> Pixar Animation Studios

There is always the failure of 'alter session kill' to deal with. On unix I habitually kill the process instead. Other people have other ideas about that (something about it being bad, aside from the danger of killing the wrong process, but I can't remember why offhand), but of course I'm only going to advocate what I do. In the past, I've seen alter session kill just leave things out there forever, since it needed to be cleaned up by smon, whereas pmon would be right on top of things. Whether this applies to 10g, I couldn't say, I'm too busy trying to figure out yet another config fragility that broke emctl on one instance but not another.

I suspect there may be an issue with TCP cleanup acknowledgement with the alter session kill, but I really don't know. I know that happens with some non-Oracle things where the parent that spawned the Oracle session has gone away. Or something like that.

jg

--
@home.com is bogus.
And they supposedly finally fix the stupid 'ps: cmd is not a valid
field name' in... 10.2.0.6GC