to pool or not to pool


Performance and scalability: to pool or not to pool

  1. to pool or not to pool (4 messages)

    I read on the allaire website that they recommend turning off connection pooling in JRun, with the argument that if you are using an enterprise database it will already pool the connections on the DB-side, and will probably do it much more efficiently than JDBC will. I'm writing a small serverside Java app that connects to an oracle database (not EJB or servlets, just a small multithreaded socket listener). Should I try to implement my own simple connection pool, or use a pre-made one, or should I leave it up to oracle?


    Threaded Messages (4)

  2. to pool or not to pool[ Go to top ]

    Wow! That is quite a shocking statement they made at Macromedia/Allaire/JRun. This is definitely countrary to common belief/practice. I wonder what kind of benchmarks they have to support their claim.

    As for your need, there are open source connection pooling libraries, such as DbConnectionBroker at and PoolMan at that you may want to take a look. If you ever decide to give Oracle MTS a try for server-side connection pooling, please share your findings with us.
  3. to pool or not to pool[ Go to top ]

    I find it fairly amazing about that. Especially since the guy who runs the (PoolMan Connection Pool Project) is also part of the JRun container development team. Could you post the URL to that?
  4. to pool or not to pool[ Go to top ]

    sure, the url is . the last section is titled "when not to use jrun connection pooling".
  5. to pool or not to pool[ Go to top ]

    It actually says that they do not recommend using JRun connection pooling when JDBC driver implements 2.0 pooling by itself - it is not the same as not using connection pooling at all ;-)