RE: [ADMIN] High memory usage [PATCH]

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(at)xythos(dot)com]
Sent: June 25, 2001 12:37 AM
To: pgsql-patches(at)postgresql(dot)org
Cc: Dave(at)micro-automation(dot)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(at)postgresql(dot)org
>>[mailto:pgsql-jdbc-owner(at)postgresql(dot)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(at)vgkk(dot)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(at)polygnosis(dot)com
>>Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
>>
>>---------------------------(end of
broadcast)---------------------------
>>TIP 1: subscribe and unsubscribe commands go to
majordomo(at)postgresql(dot)org
>>
>>
>
> [ Attachment, skipping... ]
>
>