Re: How Does IDS Handle Dead Connections?

How about the following scenario: 1. We begin a transaction 2. We do not catch the exceptions so when some situation arrives => bang 3. Meanwhile, the Resultset, Connection objects are still waiting for GarbageCollector, => locks are held 4. We are complaining about dead-connections. HTH, Radu Red Valsen wrote: > What happens internally with IDS when a connection is cut abruptly? My > developers are experiencing problems after their Java servlet > applications bomb, usually in the midst of a transaction. When they > attempt to continue a short while later, errors messages about locked > rows result, indicating that resources are still being held. > > How does Informix clean itself up in this case? How does the engine > determine whether a connection is still being held -- what are the > mechanics here? How long before it determines that an sqlexec thread is > dead? Is there a way to determine how long a connection has been > maintained, or find the origin (ie network address, username, etc) of > the connection?

Thank you for your conjecture, Radu, but I was looking for something a little more definitive about what's happening within the database server -- like something from those hard working Informix software maintenance engineers who understand the internals of the application and are trying real hard not to pay attention to their company's stock price. Radu Dumitriu wrote: > How about the following scenario: > > 1. We begin a transaction > 2. We do not catch the exceptions so when some situation arrives => bang > 3. Meanwhile, the Resultset, Connection objects are still waiting for > GarbageCollector, => locks are held > 4. We are complaining about dead-connections. > > HTH, > Radu > > Red Valsen wrote: > > > What happens internally with IDS when a connection is cut abruptly? My > > developers are experiencing problems after their Java servlet > > applications bomb, usually in the midst of a transaction. When they > > attempt to continue a short while later, errors messages about locked > > rows result, indicating that resources are still being held. > > > > How does Informix clean itself up in this case? How does the engine > > determine whether a connection is still being held -- what are the > > mechanics here? How long before it determines that an sqlexec thread is > > dead? Is there a way to determine how long a connection has been > > maintained, or find the origin (ie network address, username, etc) of > > the connection?

In article <935tb1$fvd$1@news.xmission.com>, Radu Dumitriu <radu@goldenclick.com> wrote: > > How about the following scenario: > > 1. We begin a transaction > 2. We do not catch the exceptions so when some situation arrives => bang > 3. Meanwhile, the Resultset, Connection objects are still waiting for > GarbageCollector, => locks are held > 4. We are complaining about dead-connections. > > HTH, > Radu > If the actual connection, never goes away, how can the database know to kill the connection? The only thing I know of which might help is the keep alive parameter in the sqlhosts file. You should be able to find documentation on it in the admin guide. onstat -g ntt gives good info about network activity of a session, I amnot sure if there is a matching smi table. Hope this helps, Will > Red Valsen wrote: > > > What happens internally with IDS when a connection is cut abruptly? My > > developers are experiencing problems after their Java servlet > > applications bomb, usually in the midst of a transaction. When they > > attempt to continue a short while later, errors messages about locked > > rows result, indicating that resources are still being held. > > > > How does Informix clean itself up in this case? How does the engine > > determine whether a connection is still being held -- what are the > > mechanics here? How long before it determines that an sqlexec thread is > > dead? Is there a way to determine how long a connection has been > > maintained, or find the origin (ie network address, username, etc) of > > the connection? > > Sent via Deja.com http://www.deja.com/