• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Knute Snortum
  • Paul Clapham
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Frits Walraven
Bartenders:
  • Ganesh Patekar
  • Tim Holloway
  • salvin francis

Connection Pooling vs Thread Pooling  RSS feed

 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

1. Is Connection Pooling is different from Thread Pooling?
2. If One connection will be connected to One thread...How does thread pooling is going to affect Connection Pooling?
3. How does the Connection Pool and Thread Pool plays a significant role in Blocking I/O vs Non-Blocking I/O RDBMS?
 
Saloon Keeper
Posts: 5476
143
Android Firefox Browser Mac OS X Safari Tomcat Server VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thread pooling fell out of favor long ago. There was a time when creating threads was an expensive operation - hence the idea to reuse them. But that is no longer the case, and consequently thread pools largely ceased to be used.

That is different from connection pools, which are widely used, because creating a DB connection is still a comparatively expensive operation.
 
Joseph Michael
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim,

Can you please explain each question in detail to understand better?
 
Tim Moores
Saloon Keeper
Posts: 5476
143
Android Firefox Browser Mac OS X Safari Tomcat Server VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not sure that makes sense - you seem to be under the impression that thread pooling and connection pooling are somehow related - they're not. And blocking/non-blocking IO is yet another subject. If you have a more specific question about a particular situation, we could answer in more detail.
 
Joseph Michael
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tim,

We have an application built using JDBC which is blocking I/O

JDBC will send a query to a database and hold up the thread making the query until the result comes back.

JDBC is a series of APIs that talk to a database, but is blocking.

Attempts to scale JDBC have been implemented by putting JDBC connections behind a thread pool, but when the thread pool gets saturated, it can eventually block at accepting new work, defeating the whole endeavor.

Blocking JDBC behavior requires threads to be put into I/O wait until receiving a response.

How to fix or convert the existing application which uses JDBC as Non Blocking I/O ??

Please advise.

Thanks.
 
Sheriff
Posts: 13454
222
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Again, you seem to be conflating connection pools and threads. As Tim already told you, those are different things.

Read some articles about enterprise integration pattern - fire and forget and asynchronous processing of database requests
 
Rancher
Posts: 427
6
Fedora IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Moores wrote:There was a time when creating threads was an expensive operation  


Why are they not expensive anymore?  Is it less expensive because of improvements on the hardware side or the software side?
 
Tim Moores
Saloon Keeper
Posts: 5476
143
Android Firefox Browser Mac OS X Safari Tomcat Server VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The JVM has reduced dramatically the cost of creating objects, and thread objects in particular. This happened a long time ago, 10 or 15 years, if memory serves.
 
Bartender
Posts: 20725
124
Android Eclipse IDE Java Linux Redhat Tomcat Server
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pooling is a generic construct. A pool is a collection of identical (interchangeable) objects. You petition the pool manager to return one of them, use it, and then return it so that some other task can use it. The main advantage of pooling comes when you're managing objects that take a lot of work to create. That includes things like database connections, but really anything. There is at least one generic pool library in the Apache java libraries collections. In fact, the Apache generic database connection pool itself pulls in and uses the Apache generic pool library.



Tim Moores wrote:Thread pooling fell out of favor long ago. There was a time when creating threads was an expensive operation - hence the idea to reuse them. But that is no longer the case, and consequently thread pools largely ceased to be used.



I'm sure that the people who work on web application servers such as Tomcat would be interested in hearing that.

In fact, the J2EE standard expressly forbids that servlets or EJBs should spawn threads for precisely the reason that if you return a thread to the server pool (return from servlet) and it has child threads hanging off it, you've violated the core requirement that all pool objects be identical. Which can crash the server unpredictably.
 
When you have exhausted all possibilities, remember this: you haven't - Edison. Tiny ad:
ScroogeXHTML - small and flexible RTF to HTML converter library
https://coderanch.com/t/710903/ScroogeXHTML-RTF-HTML-XHTML-converter
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!