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

Bruce,

I don't think you need to back out Dave's patch.  It works fine as it
is.  I just think it can be improved upon.

thanks,
--Barry

Bruce Momjian wrote:

> 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" <rmager@vgkk.com> 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
>>
>>
>