Неправильное использование пула соединений JDBC

Question

Я использую приложение Spring MVC, поддерживаемое базой данных MySQL, доступ к которой осуществляется с помощью JDBC.Некоторое время я использовал один и тот же код и никогда не задумывался о том, правильно ли я его использовал (правильное использование пулов соединений и т. Д.).

Я знаю, что существует JDBCTemplate там, и я подумал об его использовании, но если единственным преимуществом является то, что мне просто не нужно писать шаблонный код, то я не совсем уверен, что мне следует его использовать.На самом деле, я предпочитаю удобочитаемость моего кода, а не кода JDBCTemplate.

Ниже приведен код в моем DAO, по некоторым причинам, я чувствую, что неправильно использую ConnectionPooling.

public Agent get(Integer id){
    ConnectionPool pool = new ConnectionPool();
    Connection connection = pool.getConnection();
    PreparedStatement ps = null;
    try{
        String query = "SELECT * FROM agent where id= ?";
        ps = connection.prepareStatement(query);
        ps.setInt(1,id);
        ResultSet rs = ps.executeQuery();

        Agent agent = null;
        if(rs.next()){
            agent = new Agent();
            agent.setFirstName(rs.getString(1));
            agent.setLastName(rs.getString(2));
            agent.setStreet(rs.getString(3));
            agent.setCity(rs.getString(4));
            agent.setZip(rs.getString(5));
            agent.setState(rs.getString(6));
            agent.setUsername(rs.getString(7));
            agent.setPassword(rs.getString(8));
            agent.setId(rs.getInt(9));
            agent.setEmail(rs.getString(10));
        }
        return agent;
    }
    catch(SQLException e)
    {
        e.printStackTrace();
        return null;
    }
    finally{
        ConnectionUtility utility = new ConnectionUtility();
        utility.closePreparedStatement(ps);
        pool.freeConnection(connection);
    }
}

Код выше - это то, что меня беспокоит из-за того, что наиболее некорректно, но у меня есть несколько служебных классов, которые также могут быть причиной плохой практики / неправильного кода.

Ниже приведеномой ConnectionUtility класс.

public class ConnectionUtility{

public static void closeStatement(Statement s){
    try{
        if(s != null){
            s.close();
        }
    }
    catch(SQLException e){
        e.printStackTrace();
    }
}
public void closePreparedStatement(Statement ps){
    try{
        if(ps != null){
            ps.close();
        }
    }
    catch(SQLException e){
        e.printStackTrace();
    }
}
public static void closeResultSet(ResultSet rs){
    try{
        if(rs != null){
            rs.close();
        }
    }
    catch(SQLException e){

    }
}

}

Вот мой ConnectionPool класс,

public class ConnectionPool {
private static ConnectionPool pool = null;

public ConnectionPool(){
}
public static ConnectionPool getInstance(){
    if(pool == null){
        pool = new ConnectionPool();
    }
    return pool;
}

@SuppressWarnings("static-access")
public Connection getConnection(){
    try{

        return ConnectionFactory.getInstance().getConnection();
    }
    catch(SQLException e){
        e.printStackTrace();
        return null;
    }

}
public void freeConnection(Connection c){
    try{
        c.close();
    }
    catch(SQLException e){
        e.printStackTrace();
    }
}
}

Опять же, я чувствую, что действительно использую всеиз этих классов неправильно, хотя все работает нормально, но ничего не было проверено в производстве.

Я предпочитаю оставаться с JDBC, поэтому, пожалуйста, не советуйте переключаться на другое.

Answer 1

Одним из основных принципов Spring является внедрение зависимостей . Spring основан на убеждении, что внедрение компонентов, которые класс использует в этот класс, приводит к тому, что код легче читается, легче тестируется и легче обслуживать, чем классы / код (например, ваш get() метод) отвечает за поиск собственных зависимостей.

В качестве примера того, что это означает в более конкретных терминах: ваш метод get() зависит как минимум от двух других классов: 1) «пула соединений» и 2) самого соединения. Метод get() обладает глубокими знаниями , как он должен получить эти экземпляры.

В качестве альтернативы вашему стилю кодирования здесь, с подходом DI, класс, которому принадлежит ваш метод get(), будет вставлять в него Connection (или Datasource) (через внедрение сеттера или конструктора).

Теперь, почему это простое изменение делает код проще и лучше?

Поскольку метод get() больше не нуждается в деталях, которые не являются его основной обязанностью. Основная обязанность метода get() заключается в том, чтобы узнать, как получить Agent при Integer id. Почему этому методу также нужно знать 1) откуда брать соединения и 2) что вы хотите объединять соединения?

Что происходит, когда вы хотите изменить логику подключения? Вам нужно прикоснуться к коду каждый и каждый метод доступа к данным в вашем приложении. Это было бы намного сложнее, чем нужно.

Это сила внедрения зависимости: она позволяет вам изменять детали (например, откуда происходит соединение JDBC) без необходимости также изменять код, который использует эти детали.

Что касается вашего фактического кода пула соединений, похоже, вы неправильно понимаете две концепции:

1) Ваш ConnectionPool утверждает, что хочет быть Singleton, но вы предоставляете открытый конструктор, позволяющий соавторам по умолчанию полностью использовать единый экземпляр ConnectionPool.

2) Ваш пул соединений на самом деле не является пулом соединений! Идея пула соединений состоит в том, чтобы открыть N соединений с базой данных, а затем раздать каждое из этих N соединений коду, который требует соединения по требованию. Основная идея здесь заключается в том, что вы можете перерабатывать соединения и избегать дорогостоящих затрат на открытие нового соединения для каждого запроса. В пуле соединений, когда код, использующий соединение, выполняется с его соединением, физическое соединение фактически не прерывается - вместо этого дескриптор соединения просто возвращается в пул для повторного использования другим запросом / потоком / методом.

Самое главное, что в приложениях, использующих пул соединений, код, отвечающий за доступ к данным, обычно даже не знает, что его соединения объединяются - вместо этого DAO просто имеет ссылку на DataSource Интерфейс и DAO понятия не имеют, что на самом деле происходит, когда он запрашивает соединение DataSource, или что происходит, когда соединение освобождается. Таким образом, вы можете абстрагироваться от деталей «как мне соединиться» из кода, отвечающего за логику высшего порядка, такого как «как мне получить агента из этого целого числа?». Эта абстракция - это то, что позволяет вам изменять один слой вашего приложения, не переписывая все остальные слои - вы разъединили слои, и каждый заботится только о том, за что он действительно отвечает.

Я настоятельно рекомендую вам прочесть не только идею пула соединений, но и Внедрение зависимостей .Почему в мире вы используете Spring без компонентов DI?Что касается пулов соединений, зачем тратить время на переизобретение колеса, написав свою собственную, вместо использования ряда уже существующих и популярных библиотек, таких как commons-dbcp или c3p0 ?Вместо того, чтобы заново изобретать колесо, используйте существующую библиотеку (в которой меньше ошибок, чем в вашем домашнем решении), и сосредоточьтесь на создании реального приложения.

Answer 2

С вашим кодом есть две проблемы:

1) Вы создаете новый объект ConnectionPool для каждого вызова get().Ваш класс ConnectionPool спроектирован так, чтобы быть одноэлементным, поэтому примените его, сделав конструктор частным, и измените свой клиентский код на ConnectionPool pool = ConnectionPool.getInstance().

2) По сути, та же проблема с ConnectionUtility.У вас есть статические методы, но вы используете их нестатическим способом.Замените

ConnectionUtility utility = new ConnectionUtility();
utility.closePreparedStatement(ps);

на

ConnectionUtility.closePreparedStatement(ps);

и сделайте конструктор ConnectionUtility закрытым, а класс final.

Синглеты и служебные классы могут быть сложными, чтобы получить права,Я рекомендую вам использовать инструменты статического анализа, такие как Findbugs, для выявления подобных проблем.Он предупредит вас, когда у вас есть класс, который выглядит так, как будто он должен быть одноэлементным или служебным, но не используется таким образом.