Thread: Concurrency supported?
Hiya,
how good is concurrency supported in the JDBC driver? For example, if
I have a small process with about 50 threads, some of them requesting
large objects, will one JDBC connection suffice? If one thread is
executing a large select which takes seconds to execute, will other
threads be able to still get their results in time or do they have to
wait?
In general, are there concurrency limitations in the protocol
PostgreSQL uses?
Regards
--
Ingo Luetkebohle / ingo@blank.pages.de / 95428014
/
| Student of Computational Linguistics & Computer Science;
| Fargonauten.DE sysadmin; Gimp Registry maintainer;
| FP: 3187 4DEC 47E6 1B1E 6F4F 57D4 CD90 C164 34AD CE5B
----- End forwarded message -----
--
Ingo Luetkebohle / ingo@blank.pages.de / 95428014
/
| Student of Computational Linguistics & Computer Science;
| Fargonauten.DE sysadmin; Gimp Registry maintainer;
| FP: 3187 4DEC 47E6 1B1E 6F4F 57D4 CD90 C164 34AD CE5B
Ingo Luetkebohle writes: > how good is concurrency supported in the JDBC driver? For example, if > I have a small process with about 50 threads, some of them requesting > large objects, will one JDBC connection suffice? If one thread is > executing a large select which takes seconds to execute, will other > threads be able to still get their results in time or do they have to > wait? > > In general, are there concurrency limitations in the protocol > PostgreSQL uses? See http://www.postgresql.org/devel-corner/docs/postgres/jdbc-thread.html -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut wrote: > > Ingo Luetkebohle writes: > > > how good is concurrency supported in the JDBC driver? For example, if > > I have a small process with about 50 threads, some of them requesting > > large objects, will one JDBC connection suffice? If one thread is > > executing a large select which takes seconds to execute, will other > > threads be able to still get their results in time or do they have to > > wait? > > > > In general, are there concurrency limitations in the protocol > > PostgreSQL uses? > > See http://www.postgresql.org/devel-corner/docs/postgres/jdbc-thread.html > Someone might want to add that different threads can't use the same connection if they are using transaction blocks. -- Joseph Shraibman jks@selectacast.net Increase signal to noise ratio. http://www.targabot.com
At 02:20 25/02/01 +0100, Ingo Luetkebohle wrote: >Hiya, > >how good is concurrency supported in the JDBC driver? For example, if >I have a small process with about 50 threads, some of them requesting >large objects, will one JDBC connection suffice? If one thread is >executing a large select which takes seconds to execute, will other >threads be able to still get their results in time or do they have to >wait? They have to wait as there is only one physical network connection. To get round this, you need to use a Connection pool. >In general, are there concurrency limitations in the protocol >PostgreSQL uses? Only 1 action can occur at one time, be it an SQL query or a FastPath command. The JDBC driver however ensures that only one Thread has ownership of the connection at any one time. Peter
At 19:44 26/02/01 -0500, Joseph Shraibman wrote: >Peter Eisentraut wrote: > > > > Ingo Luetkebohle writes: > > > > > how good is concurrency supported in the JDBC driver? For example, if > > > I have a small process with about 50 threads, some of them requesting > > > large objects, will one JDBC connection suffice? If one thread is > > > executing a large select which takes seconds to execute, will other > > > threads be able to still get their results in time or do they have to > > > wait? > > > > > > In general, are there concurrency limitations in the protocol > > > PostgreSQL uses? > > > > See http://www.postgresql.org/devel-corner/docs/postgres/jdbc-thread.html > > > >Someone might want to add that different threads can't use the same >connection if they are using transaction blocks. Actually this is a common missconception with the JDBC spec. I don't know why they put the transaction stuff at the Connection level, but it means that any JDBC connection can only have one transaction. Perhaps something along those lines, or: You cannot use different threads while using transactions. If your application does a lot of queries but only a few updates, try to have the updates done in their own Connections, and use the Connection pool for the queries. Peter >-- >Joseph Shraibman >jks@selectacast.net >Increase signal to noise ratio. http://www.targabot.com
On Thu, Mar 01, 2001 at 08:03:29PM +0000, Peter Mount wrote:
> They have to wait as there is only one physical network connection. To get
> round this, you need to use a Connection pool.
After the information I got here, I arrived at that, too. However,
explicitly releasing a resource (as is necessary to put a Connection
back into the pool) is not something the Java designers meant to
happen. This becomes painfully obvious when looking at JavaServer
Pages where you don't have a 'finally' block built into the system.
OTOH, I might be missing something obvious. In any case, using a pool
works so I'm not really complaining :)
--
Ingo Luetkebohle / ingo@blank.pages.de / 95428014
/
| Student of Computational Linguistics & Computer Science;
| Fargonauten.DE sysadmin; Gimp Registry maintainer;
| FP: 3187 4DEC 47E6 1B1E 6F4F 57D4 CD90 C164 34AD CE5B