Received: from thor.candleweb.no (thor.candleweb.no [195.139.160.194])
	by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f0J0xP034593
	for <pgsql-interfaces@postgresql.org>;
	Thu, 18 Jan 2001 19:59:25 -0500 (EST)
	(envelope-from gunnar@candleweb.no)
Received: (from gunnar@localhost) by thor.candleweb.no (8.10.0/8.10.0/on4)
	id <f0J0rvc19184>; Fri, 19 Jan 2001 01:53:57 +0100 (MET)
To: Barry Lind <barry@xythos.com>
Cc: Peter Mount <peter@retep.org.uk>, pgsql-interfaces@postgresql.org
Subject: Re: [PATCHES] Re: Fixes and enhancements to JDBC driver (take 2)
References: 
 <Pine.LNX.4.10.10101171425190.26916-200000@polymorphic.microstate.com>
	<x6bst5dl7g.fsf@thor.candleweb.no> <3A676B76.77944038@xythos.com>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
From: Gunnar R|nning <gunnar@candleweb.no>
Date: 19 Jan 2001 01:53:57 +0100
In-Reply-To: Barry Lind's message of "Thu, 18 Jan 2001 14:17:26 -0800"
Message-ID: <x68zo8qs4a.fsf@thor.candleweb.no>
Lines: 40
X-Mailer: Gnus v5.4.65/Emacs 19.34
X-Archive-Number: 200101/210
X-Sequence-Number: 828

Barry Lind <barry@xythos.com> writes:

> Gunner,
> 
> Do your fixes address the concerns I raised on 12/21?  (I have included
> that email to the list below).  To summarize the three major
> concerns/bugs were:
> 1) Code incorrectly deallocates when a new statement is executed, even
> though the byte[]s are still being used.
> 2) The cache isn't limited in size, resulting in essentially memory
> leaks for long lived connections in a connection pool.
> 3) The implementation is limited to a max 256 byte byte[], whereas my
> queries have many values that exceed this size, and the current
> implementation doesn't lend itself well (because of #2) to cache things
> upto 8K in size.

The original patch that I supplied was a proof of concept on what kind of
performance improvements that could be made by reusing byte arrays. This
was unfortunately committed before anybody but me had done any testing at
all on it. 

The most serious problem with this code was your issue 1). Number 2) and 3)
should be easy to handle has config parameters. The reason for hardcoding
3) to 256 was simply because I found this to be the most optimal value for
the web application I was doing the testing on.

Eventually, it should be configurable whether to use the byte[] caching
implementation or not, as the perfomance of memory allocation may vary
greatly depending on VM and OS implementations.

If you go back to the October archives of pgsql-general you will find a
pointer to my second shot at an implementation - this one fix your issue 1)
but not the others.

I would like to see what you have been working on as well, so we can come
up with the best of breeds solution. 

Regards, 

	Gunnar