Re: [PATCHES] Re: [INTERFACES] Patch for JDBC timestamp problems
От | Joseph Shraibman |
---|---|
Тема | Re: [PATCHES] Re: [INTERFACES] Patch for JDBC timestamp problems |
Дата | |
Msg-id | 3A760360.DA37F1C@selectacast.net обсуждение исходный текст |
Ответ на | Re: [PATCHES] Re: [INTERFACES] Patch for JDBC timestamp problems (Michael Stephenson <mstephenson@tirin.openworld.co.uk>) |
Ответы |
Re: [PATCHES] Re: [INTERFACES] Patch for JDBC timestamp problems
Re: Re: [PATCHES] Re: [INTERFACES] Patch for JDBC timestamp problems |
Список | pgsql-jdbc |
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. > 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
В списке pgsql-jdbc по дате отправления: