In JDBC, “database timeouts” can mean a few different things, and you handle each at a different layer. The most practical approach is to set timeouts deliberately and then catch the right exception types so you can decide whether to retry, fail fast, or surface a user-friendly error.

1) Connection timeout (can’t connect / handshake takes too long)

a) DriverManager login timeout (global)

This limits how long DriverManager will wait when establishing a connection.

package org.kodejava.jdbc;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

public class ConnectTimeoutExample {
    public static void main(String[] args) throws SQLException {
        DriverManager.setLoginTimeout(10); // seconds

        try (Connection c = DriverManager.getConnection(
                "jdbc:mysql://localhost/kodejava",
                "kodejava",
                "s3cr*t"
        )) {
            // connected
        }
    }
}

b) Driver-specific connect/socket timeouts (recommended)

Most drivers expose properties like connectTimeout and socketTimeout (names vary by vendor). These are often more reliable than setLoginTimeout.

Example pattern using connection properties:

package org.kodejava.jdbc;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.util.Properties;

public class DriverPropertiesTimeoutExample {
    public static void main(String[] args) throws SQLException {
        Properties props = new Properties();
        props.setProperty("user", "kodejava");
        props.setProperty("password", "s3cr*t");

        // Vendor-specific keys; check your driver docs:
        props.setProperty("connectTimeout", "10000"); // ms (example)
        props.setProperty("socketTimeout", "30000");  // ms (example)

        try (Connection c = DriverManager.getConnection(
                "jdbc:mysql://localhost/kodejava",
                props
        )) {
            // ...
        }
    }
}

Rule of thumb: set both a connect timeout and a read/socket timeout, otherwise a query can hang at the network layer even if you set a query timeout.

---

2) Query execution timeout (a statement runs too long)

Use Statement.setQueryTimeout(int seconds) (works for Statement, PreparedStatement, CallableStatement). On timeout, drivers typically throw a SQLTimeoutException (a subclass of SQLException).

package org.kodejava.jdbc;

import java.sql.*;

public class QueryTimeoutExample {
    public static void main(String[] args) throws SQLException {
        try (Connection c = DriverManager.getConnection("jdbc:mysql://localhost/kodejava", "kodejava", "s3cr*t");
             PreparedStatement ps = c.prepareStatement("SELECT * FROM product WHERE price > ?")) {

            ps.setBigDecimal(1, new java.math.BigDecimal("100.00"));
            ps.setQueryTimeout(5); // seconds

            try (ResultSet rs = ps.executeQuery()) {
                while (rs.next()) {
                    // consume results
                }
            }
        } catch (SQLTimeoutException e) {
            // This is your “query took too long” bucket.
            throw new RuntimeException("Query timed out; consider optimizing SQL or raising timeout.", e);
        }
    }
}

Important notes:

• setQueryTimeout is enforced by the driver, and behavior can differ:
  • Some drivers send a cancel to the server.
  • Some only time out client-side.
• If the thread is interrupted, or you want a manual escape hatch, you can also call Statement.cancel() from another thread.

---

3) Lock wait / deadlock timeouts (transaction waits too long)

These are not “JDBC timeouts” per se—they’re database concurrency timeouts. They usually surface as SQLException with:

• SQLState like 40001 (serialization failure / deadlock, DB-dependent), or
• vendor-specific error codes/messages (e.g., lock wait timeout exceeded).

Handling strategy:

• Rollback the transaction.
• Retry only if you can safely retry (best is retrying the whole transaction), and keep attempts small with backoff.

---

4) Pool acquisition timeout (you can’t get a Connection from the pool)

If you use a pool (HikariCP, DBCP, c3p0, etc.), also set a connection acquisition/checkout timeout. Otherwise, under load you’ll see “timeouts” that are actually “all connections are busy.”

This is configured on the pool, not via JDBC calls.

---

5) Catching and classifying timeouts correctly

Catch the specific subtype when possible

JDBC provides SQLTimeoutException:

try {
    // execute query/update
} catch (SQLTimeoutException e) {
    // query timeout bucket
} catch (SQLException e) {
    // everything else
}

Use SQLState for broad categories

If you need portability, SQLState prefixes help:

• 08xxx → connection exception family (network/connection problems)
• 40xxx → transaction rollback / concurrency issues (often retryable depending on DB)

static boolean isConnectionProblem(SQLException e) {
    String state = e.getSQLState();
    return state != null && state.startsWith("08");
}

---

6) Retry policy (only for the right failures)

Retries are useful for transient failures (deadlocks, lock timeouts, brief network blips), but dangerous for non-idempotent operations.

A safe baseline:

• Retry 2–3 times max
• Use jittered backoff
• Retry only when:
  • you can retry the entire transaction, or
  • the operation is idempotent

Sketch:

package org.kodejava.jdbc;

import java.sql.SQLException;
import java.sql.SQLTimeoutException;
import java.time.Duration;
import java.util.concurrent.ThreadLocalRandom;

public class RetrySupport {
    public static <T> T withRetry(SqlSupplier<T> work) throws SQLException {
        int maxAttempts = 3;
        SQLException last = null;

        for (int attempt = 1; attempt <= maxAttempts; attempt++) {
            try {
                return work.get();
            } catch (SQLTimeoutException e) {
                // Query timed out: retry is usually NOT helpful unless you expect transient load.
                throw e;
            } catch (SQLException e) {
                last = e;
                if (!isRetryable(e) || attempt == maxAttempts) throw e;

                sleep(backoff(attempt));
            }
        }
        throw last; // unreachable
    }

    private static boolean isRetryable(SQLException e) {
        String state = e.getSQLState();
        if (state != null && state.startsWith("08")) return true;  // connection hiccup
        if (state != null && state.startsWith("40")) return true;  // tx rollback class (DB-dependent)
        return false;
    }

    private static Duration backoff(int attempt) {
        long baseMs = 100L * (1L << (attempt - 1)); // 100, 200, 400...
        long jitter = ThreadLocalRandom.current().nextLong(0, 100);
        return Duration.ofMillis(baseMs + jitter);
    }

    private static void sleep(Duration d) {
        try {
            Thread.sleep(d.toMillis());
        } catch (InterruptedException ie) {
            Thread.currentThread().interrupt();
        }
    }

    @FunctionalInterface
    public interface SqlSupplier<T> {
        T get() throws SQLException;
    }
}

---

7) Practical checklist (what to set in real apps)

1. Pool acquisition timeout (if using a pool)
2. Connect timeout (driver property)
3. Socket/read timeout (driver property)
4. Query timeout (setQueryTimeout)
5. For transactions:
   • keep transactions short
   • handle deadlocks/lock timeouts with rollback and bounded retry