Message-ID: <3A760360.DA37F1C@selectacast.net>
Date: Mon, 29 Jan 2001 18:57:20 -0500
From: Joseph Shraibman <jks@selectacast.net>
Organization: Xtenit, Inc. http://www.xtenit.com
MIME-Version: 1.0
To: Michael Stephenson <mstephenson@tirin.openworld.co.uk>
CC: PostgreSQL jdbc list <pgsql-jdbc@postgresql.org>
Subject: Re: [PATCHES] Re: [INTERFACES] Patch for JDBC timestamp problems
References: <Pine.LNX.4.30.0101250949190.20707-100000@tirin.openworld.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Michael Stephenson wrote:
> 
> On Wed, 24 Jan 2001, Joseph Shraibman wrote:
> 
> > > What was the conclusion of this discussion?  Do we leave it static?
> >
> > No, it cannot be static.
> 
> As I see it we have three possible solutions to this problems.
> 
> a) Just stop it being static, each PreparedStatement gets a new
>    instantiation (I think this is what we've done for now).
> b) static ThreadLocal, each Thread gets one instantiation.

But I think some people are still using java 1.1.x and they don't have
ThreadLocal.

> c) An Object Pool (possibly using SoftReferences to stop memory bloat),
>    slightly more difficult to code, a lot less instantiations, much
>    better performance.

But there are so many different ones used and you would have to make a
pool for each one.

> 
> If people agree that either 'b' or 'c' is a better solution, I'll go ahead
> and implement it.

I don't agree.  Part of java performance is memory usage.  Introducing
memory pools means keeping objects around forever even if they are used
once.  In tests I've done to see if using static variables are usful
with string parsing I've found that gain is minimal.  Any call to
postgress will be disk and network bound and trying to introduce a pool
will only complicate things.

-- 
Joseph Shraibman
jks@selectacast.net
Increase signal to noise ratio.  http://www.targabot.com