Re: [cx-oracle-users] Connecting to a database in a way that doesn't stop a shutdown
Brought to you by:
atuining
From: Paul M. <p.f...@gm...> - 2005-09-12 14:12:30
|
On 9/12/05, Amaury Forgeot D Arc <Ama...@ub...> wrote: > I've never used the Intelligent agent, but it seems on the contrary=20 > that a running agent is one of the causes which prevent=20 > SHUTDOWN NORMAL to work.=20 > A quick Google search reveals that some DBAs include a=20 > "agentctl stop" command in their shutdown procedures.=20 Hmm, I was sure I'd seen agent connections on a database which stopped happily with SHUTDOWN NORMAL. Maybe I was mistaken... I don't have a system I can do a realistic test of this on at the moment, unfortunately :-( > You should try to solve your case differently. Here are some ideas:=20 >=20 > - replace SHUTDOWN NORMAL by SHUTDOWN TRANSACTIONAL, which > closes the connection after COMMIT or ROLLBACK. To be honest, I would expect most shutdowns to be IMMEDIATE (or at least to do IMMEDIATE if NORMAL doesn't respond within a reasonable time). However, I'm not 100% certain that's the case - and I really don't want to block a production system shutdown just because I wasn't aware of it! =20 > - Implement some kind of connection pooling, where the connection=20 > object is closed after 10 minutes of idle time.=20 > For this you will need another thread to close the connection.=20 That might work, although I expect the connections to spend most of their time idle. The only reason I'm bothering about this is to increase responsiveness of an application querying many databases, with very small queries, where I want to avoid the issue of the connect time dominating the response. Maybe it's simplest just to accept the hit, and connect when needed - I can multithread the connections, so that I'm only limited by the response of the slowest connection. > - Use the Oracle "Profiles" feature, and limit the "idle time"=20 > for the session.=20 Not really an option, as it needs changes to the target databases, where I don't have that flexibility. A connection pool would probably be better for my specific requirements here. > Hope this helps,=20 It does, thanks. Paul. |