Re: [INTERFACES] libpq and multi-threading on Linux?
От | Peter T Mount |
---|---|
Тема | Re: [INTERFACES] libpq and multi-threading on Linux? |
Дата | |
Msg-id | Pine.LNX.4.04.9902151942110.29227-100000@maidast.retep.org.uk обсуждение исходный текст |
Ответ на | Re: [INTERFACES] libpq and multi-threading on Linux? (Michael Olivier <molivier@yahoo.com>) |
Список | pgsql-interfaces |
On Mon, 15 Feb 1999, Michael Olivier wrote: > Peter - thanks for your response -- see comments below. > > ---Peter T Mount <peter@retep.org.uk> wrote: > > > > On Wed, 10 Feb 1999, Michael Olivier wrote: > > > > > Hi folks, > > > > > > I apologize in advance if I have overlooked docs, but I haven't been > > > able to find a discussion of how PostGreSQL via libpq on Linux fares > > > with pthreads. Can someone point me to docs if available, or > otherwise > > > enlighten me? How well does it work and what are the important > design > > > issues to consider? > > > > > > I'm expecting to create a pool of db connections to use within a > > > long-running process, which will create a new thread for each > incoming > > > request from a client. I've found just a very little bit about PG > > > being multi-processing, but not how it will interact with a > > > multi-threaded client. I appreciate your comments. > > > > Take a look on how I got the JDBC driver to handle multi-threading. > > OK, great -- how do I get this? From looking at your web site, I can > see downloadable jdbc6.4.jar, but I'm not doing Java work so don't > have a way to access this - looks like an archive. I should have said look at the source. The .jar files on my site contain just the pre-compiled .class files. Oh, you can use any zip tool to expand a jar file. > Can you send me the source file(s) or post a URL? It's under the src/interfaces/jdbc directory in the main source tree. > > At certain points, the driver obtains a lock on the network connection > > before sending a query, and releases the lock when the query has > finished > > (ie: all results have been returned in to the ResultSet). > > Is this so several threads can share one connection, or so that > Postgresql doesn't get screwed up with different threads using > different connections? I think you're saying the former, but I'm not > sure. It's the former. Usually most people only run one connection per thread, but just in case, the locking of the connection gives us some protection. > I'm looking at allocating one connection per thread, so I need > this clarified, i.e., do I need to do locking of some sort or will it > work for me that each thread has a unique DB connection? What you need is a pool of connections. In the current development source, there is an example of a pool of connections in the JDBC-CORBA example. It's under src/interfaces/jdbc/example/corba > > I'm not sure if this is what you were after. > > Yes, it's getting at it. Thanks. -- Peter T Mount peter@retep.org.uk Main Homepage: http://www.retep.org.uk PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres Java PDF Generator: http://www.retep.org.uk/pdf
В списке pgsql-interfaces по дате отправления: