Received: from mail.retep.org.uk ([216.126.85.184]) by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f0UDhDq16686 for ; Tue, 30 Jan 2001 08:43:13 -0500 (EST) (envelope-from peter@retep.org.uk) Received: (from nobody@localhost) by mail.retep.org.uk (8.11.1/8.11.1) id f0UDh4D16673; Tue, 30 Jan 2001 08:43:04 -0500 (EST) (envelope-from peter@retep.org.uk) X-Authentication-Warning: mail.retep.org.uk: nobody set sender to peter@retep.org.uk using -f To: Joseph Shraibman Subject: Re: Re: [PATCHES] Re: [INTERFACES] Patch for JDBC timestamp problems Message-ID: <980862184.3a76c4e8bf0e6@webmail.retep.org.uk> Date: Tue, 30 Jan 2001 08:43:04 -0500 (EST) From: Peter T Mount Cc: Michael Stephenson , PostgreSQL jdbc list References: <3A760360.DA37F1C@selectacast.net> In-Reply-To: <3A760360.DA37F1C@selectacast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Archive-Number: 200101/96 X-Sequence-Number: 101 Quoting Joseph Shraibman : > 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. True, except the 1.1 & 1.2 implementations are different packages, so you simply don't do ThreadLocal in 1.1.x > > 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 > -- Peter Mount peter@retep.org.uk PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/ RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/