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: neutral (asf.osuosl.org: local policy)
Message-ID: <42C58C8D.3030309@debrunners.com>
Date: Fri, 01 Jul 2005 11:33:49 -0700
From: Daniel John Debrunner <djd@debrunners.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: Statement.setQueryTimeout() in client/server mode
References: <42C5570F.2030307@sun.com>
In-Reply-To: <42C5570F.2030307@sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Oyvind.Bakksjo@Sun.COM wrote:
> Currently, the Derby client contains a client-side implementation of
> setQueryTimeout; using a TimerTask to invoke Statement.cancel() on the
> client side. First of all, cancel() is not implemented, so this doesn't
> work. Furthermore, we should use the server-side mechanism we now have
> for statement timeouts.

> For this, we need to transfer the timeout value from the client to the
> server, preferable without a separate round-trip. I have some loose
> thoughts on how to do this:

I'm not so sure, the reason is that the client side query timeout is
performing additional or different work. The client side needs to
timeout if the server has not responded within the given time, this
includes communication problems between the client and server.

So assume we have to fix the network communication problem, so the
client times out and cancels the statement if it has no received no
response from the server. Now if this is done, what is the advantage of
also pushing the timeout value to the server? You now have two timeouts
running, performing exactly the same operation. And most likely the
client one will fire first as it is set up first.

Dan.