Managing database connections in multi-threaded socket server

Question

I have a simple udp server that accepts packets, decodes the packets and inserts them into the database. Since there can be 100,000 concurrent connections, each with time-sensitive data, the data needs to be inserted into the database as quickly as possible.

In order to acheive this, I use a ExecutorService with 50 threads. When packet comes in, one of the threads in pool is used to process the data:

// UdpServer

public void run() {

    ExecutorService executor = Executors.newFixedThreadPool(50);        

    while (listening) {
        try {
            byte[] buf = new byte[256];

            DatagramPacket packet = new DatagramPacket(buf, buf.length);
            socket.receive(packet);

            executor.execute(new Responder(socket, packet));                
        } catch (IOException e) {
            e.printStackTrace();
        }
    }       
}

Since I have a thread pool, I figured I didn't need a database pool, because at start up each thread can open a database connection. So this is what I did for each Responder thread:

// Responder class

public void run() {         
    this.connection = DriverManager.getConnection(url, username, password);
    processPacket();
    connection.close();
}

private void processPacket(){
    Report report = ReportParser.readReport(packet);
    report.setConnection(connection);
    report.save();
}     

// Report class

public void save(){
    stmt = connection.createStatement();
    rs = stmt.executeQuery(...);
}

The problem is it seems when the program starts, it doesn't immediately establish the database connections for each thread. When the packet is sent to server, there is several seconds delay before data is inserted, and this is only one packet. Imagine 100,000.

Would I be better off using aa database pool (like BoneCP) in combination with the thread pool, or would the database pool not aid performance in this situation?

Answer 1

Thread pools and database pools have their own purpose. I don't think one can replace the other. Using a database pool, you can rely on them to provide your threads an existing db connection. So IMPO i would go with a database pool along with your DB push thread pool.