Re: RE: [ADMIN] High memory usage [PATCH]

Barry, let me back out Dave's change until we can all agree on it, OK? 
It is easy to do.

> Barry,
> 
> My patch was attempting to maintain some sort of thread safety. I do not
> think the if (df==null) test is thread-safe. It would need to be
> synchronized.
> 
> However, as I have mentioned in a couple of previous posts; I'm not sure
> thread-safety is worthwhile. The driver appears to be thread safe in
> that multiple threads can each use different instances of connections,
> and statements, and resultset's however I don't think it is thread safe
> in the sense that multiple threads could use the same instance of the
> above objects. The JDBC guide suggests that the driver s/b threadsafe in
> this sense (multiple threads....same object). The guide suggests that
> one thread may instigate the retrieval of a result set, and another
> would display it.
> 
> 
> Where this is leading is: What kind of thread safety are we trying to
> achieve? 
> 
> If it's only one instance per thread then, I would have to agree that
> Barry's patch s/b applied.
> 
> P.S. 
> 
> Is there a formal process within the postgres group for making these
> kind of decisions. 
> 
> If not I would like to suggest adopting the apache groups +1,-1 voting
> approach.
> 
> -----Original Message-----
> From: Barry Lind [mailto:blind@xythos.com] 
> Sent: June 25, 2001 12:37 AM
> To: pgsql-patches@postgresql.org
> Cc: Dave@micro-automation.net; 'PostgreSQL jdbc list'
> Subject: Re: [ADMIN] High memory usage [PATCH]
> 
> Since this patch got applied before I got around to commenting on it, I 
> have submitted a new patch to address my issues with the original patch.
> 
> The problem with the patch as applied is that is always creates the 
> SimpleDateFormat objects in the constructor of the PreparedStatement 
> regardless of whether or not they will ever be used in the 
> PreparedStatement.  I have reverted back to the old behavior that only 
> creates them if necessary in the setDate and setTimestamp methods.
> 
> I also removed the close() method.  It's only purpose was to free these 
> two SimpleDateFormat objects.  I think it is much better to leave these 
> two objects cached on the thread so that other PreparedStatements can 
> use them.  (This was the intention of a patch I submitted back in 
> February where I was trying to remove as many object creations as 
> possible to improve performance.  That patch as written needed to get 
> pulled because of the problem that SimpleDataFormat objects are not 
> thread safe.  Peter then added the ThreadLocal code to try to solve the 
> performance problem, but introduced the memory leak that originated this
> 
> email thread.)  I think the cost of at most two SimpleDateFormat objects
> 
> being cached on each thead is worth the benefits of less object creation
> 
> and subsequent garbage collection.
> 
> thanks,
> --Barry
> 
> 
> Bruce Momjian wrote:
> 
> > Patch applied.  Thanks.
> > 
> > 
> >>Here is a patch which inspired by Michael Stephens that should work
> >>
> >>Dave
> >>
> >>
> >>-----Original Message-----
> >>From: pgsql-jdbc-owner@postgresql.org
> >>[mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Gunnar R?nning
> >>Sent: June 22, 2001 10:14 AM
> >>To: Rainer Mager
> >>Cc: Dave Cramer; Bruce Momjian; PostgreSQL jdbc list
> >>Subject: Re: [JDBC] Re: [ADMIN] High memory usage [PATCH]
> >>
> >>* "Rainer Mager"  wrote:
> >>|
> >>
> >>| Interesting. I wasn't aware of this. If question #2 is answered such
> >>that
> >>| thread safe isn't necessary, then this problem goes away pretty
> >>easily. If
> >>| thread safety is needed then this would have to be rewritten, I can
> >>look
> >>| into doing this if you like.
> >>
> >>Thread safety is required by the spec. Do you have "JDBC API tutorial
> >>and 
> >>reference, 2 ed." from Addison Wesley ? This book contains a section
> for
> >>
> >>JDBC driver writers and explains this issue.
> >>
> >>regards, 
> >>
> >>        Gunnar
> >>
> >>-- 
> >>Gunnar R?nning - gunnar@polygnosis.com
> >>Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
> >>
> >>---------------------------(end of
> broadcast)---------------------------
> >>TIP 1: subscribe and unsubscribe commands go to
> majordomo@postgresql.org
> >>
> >>
> > 
> > [ Attachment, skipping... ]
> > 
> > 
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026