Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <35B32B50-1AA6-11D9-906D-003065905854@nonintuitive.com>
References: <m3oejbqcuz.fsf@yesco.org>
 <35B32B50-1AA6-11D9-906D-003065905854@nonintuitive.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <6AEF5600-1BDE-11D9-8514-003065CBB010@nonintuitive.com>
Content-Transfer-Encoding: 7bit
From: Andrew McIntyre <fuzzylogic@nonintuitive.com>
Subject: Re: Help detecting client disconnects for network server
Date: Mon, 11 Oct 2004 16:36:47 -0700
To: "Derby Development" <derby-dev@db.apache.org>

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