db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew McIntyre <fuzzylo...@nonintuitive.com>
Subject Re: Help detecting client disconnects for network server
Date Mon, 11 Oct 2004 23:36:47 GMT
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


Mime
View raw message