On Oct 10, 2004, at 3:21 AM, Samuel Andrew McIntyre wrote:
Why not just decide that 'X' (m)secs without response indicates that a failure has occurred of enough significance to cancel a pending transaction?
To expand on this:
What if the embedded instance that network server is connecting to allowed setting an upper limit on the amount of time any transaction can take? Then, when this limit is hit regardless what state server and client is in the database rolls back the transaction, and the locks are released anyway. Network server would still need to do cleanup of the client connection, but at least that would solve the problem of locks being held indefinitely.
A configurable upper limit to the life of any transaction that holds a lock seems like it would be a good thing to have, even for embedded and not just for Network Server. At some point, lack of communication means that something has gone wrong, whether it is a communications or systems error, and we should probably rollback the transaction and release the locks to let processing continue. This is what DB2 for z/OS does - keep track of which threads hold locks and time them out according to an attribute of the connection:
http://publib.boulder.ibm.com/infocenter/dzichelp/topic/ com.ibm.db2.doc.admin_8.1.0/bjndmstr613.htm (for z/OS, idle thread timeout parameter, note they also suggest setting your keepalive value low if you're really worried about resource consumption)
Strangely, I couldn't find anything on how Oracle or DB2 UDB would handle such a situation, even regarding behavior with respect to TCP keepalive. Does anyone know how this is handled in other databases?
I suppose this might be overly complicated to implement, considering what we're after, but it would address the problem.
andrew
