Re: RE: [ADMIN] High memory usage [PATCH]
От | Bruce Momjian |
---|---|
Тема | Re: RE: [ADMIN] High memory usage [PATCH] |
Дата | |
Msg-id | 200106251459.f5PExBq05274@candle.pha.pa.us обсуждение исходный текст |
Ответ на | RE: [ADMIN] High memory usage [PATCH] ("Dave Cramer" <Dave@micro-automation.net>) |
Список | pgsql-jdbc |
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 > -- 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
В списке pgsql-jdbc по дате отправления: