Re: How Does IDS Handle Dead Connections?

Ok, sorry, let's try to restate it: Your last questions: net addr, username => onstat -g ses; syssessions same as above + time of the connect-> syssessions; kept as result of the time() call However, your engine does not have any dead connections, and this what I tried to show you. The connections are still valid from the Ifmx point of view as I explain earlier. It's a huge difference between "unused" connections and "broken" ones. I guess :-) that the cleanup of the connection is made when the select() system call indicates that a fd has an exception; this is not your case. For more info do a "man select" and take a look at the 4th parameter if I remember well. HTH, Radu Red Valsen wrote: > 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?