there’s some logic/intelligence involved in pool growth/shrinking, conn reclaim … That logic is somehow provided by the servlet container, within the same JVM. I think it’s provided by the “swimming pool manager”.
“container-managed conn pooling” is a common phrase. Servlet Container maintains a pool of connection objects — each a chunk of memory.
A primitive implementation is a hashmap in the container’s memory, A hashmap of physical (ie in-memory) PooledConnection objects.
“swimming pool manager” is a boundless (can’t bypass) wall between the servlets and the pool of PooledConnection objects, and exposes to the servlets essentially 2 methods — getConnection() and closeConnection() . Not sure about the method names. Reacting to these calls, the swimming pool manager hands out or reclaims a “physical” connection from the servlet to the pool.
“swimming pool manager” is the single “spokesman” and single point of access of the pool.
“swimming pool manager” is request-driven. I think a class will “send it a message” by calling poolManager.getConnection() or poolManager.closeConnection()
In Weblogic, a swimming pool manager (the hashmap of conn objects) may need 2 helpers — dataSource and a pool driver.
* i think u need to specify the driver in your jdbc calls
* You can choose to use dataSource when obtaining a connection from the swimming pool manager.