Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Yes, you should consider re-using connections rather than creating a new one each time. The usual procedure is:</p> <ul> <li>make some guess as to how many simultaneous connections your database can sensibly handle (e.g. start with 2 or 3 per CPU on the database machine until you find out that this is too few or too many-- it'll tend to depend on how disk-bound your queries are)</li> <li>create a <strong>pool</strong> of this many connections: essentially a class that you can ask for "the next free connection" at the beginning of each method and then "pass back" to the pool at the end of each method</li> <li>your getFreeConnection() method needs to return a free connection if one is available, else either (1) create a new one, up to the maximum number of connections you've decided to permit, or (2) if the maximum are already created, wait for one to become free</li> <li>I'd recommend the Semaphore class to manage the connections; I actually have a short article on my web site on <a href="http://www.javamex.com/tutorials/synchronization_concurrency_semaphore2.shtml" rel="noreferrer">managing a resource pool with a Semaphore</a> with an example I think you could adapt to your purpose</li> </ul> <p>A couple of practical considerations:</p> <ul> <li>For optimum performance, you need to be careful <strong>not to "hog" a connection while you're not actually using it to run a query</strong>. If you take a connection from the pool once and then pass it to various methods, you need to make sure you're not accidentally doing this.</li> <li>Don't forget to return your connections to the pool! (try/finally is your friend here...)</li> <li>On many systems, you <strong>can't keep connections open 'forever'</strong>: the O/S will close them after some maximum time. So in your 'return a connection to the pool' method, you'll need to think about <strong>'retiring' connections that have been around for a long time</strong> (build in some mechanism for remembering, e.g. by having a <strong>wrapper object</strong> around an actual JDBC Connection object that you can use to store metrics such as this)</li> <li>You may want to consider using prepared statements.</li> <li>Over time, you'll probably need to <strong>tweak the connection pool size</strong></li> </ul>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload