Создание пула соединений с базой данных

Ваш вопрос несколько двусмыслен:

Вы хотите доработать реализацию пула соединений? Если это так, это хорошая отправная точка: http://java.sun.com/developer/onlineTraining/Programming/JDCBook/conpool.html Но это крайне не рекомендуется для производственных сред. Лучше использовать существующий и тщательно протестированный API пула соединений, например DBCP или C3P0.

Или вы хотите знать, как использовать пул соединений? Если да, то ответ зависит от используемого API пула соединений. К счастью, обычно он доступен на веб-сайте соответствующего API.

Или вы хотите знать, когда/почему использовать пул соединений? Если это так, это, безусловно, повысит производительность подключения, если у вас есть долгоживущее приложение (например, веб-приложение) и вам нужно подключать базу данных более чем часто. Обычная практика JDBC заключается в следующем: получить и закрыть Connection, Statement и ResultSet в кратчайшей возможной области (т. е. внутри одного и того же блока методов). Поскольку подключение довольно дорогое и может занять до 200 мс или даже больше, использование пула подключений намного быстрее. Он предоставляет соединения по запросу и заботится о фактическом закрытии соединения. Это, однако, не означает, что вы можете изменить способ написания JDBC, вам все равно нужно приобретать и закрывать их в максимально возможной степени. Единственное, что вам нужно изменить, это способ подключения. Например. меняться от

connection = driverManager.getConnection();

to

connection = connectionPool.getConnection();

Больше никаких изменений не требуется, пока ваш код JDBC хорошо написан.

Вступительная страница к Apache DBCP хорошо подводит итог:

Создание нового подключения для каждого пользователя может занять много времени (часто требуется несколько секунд по часам), чтобы выполнить транзакцию базы данных, которая может занять миллисекунды. Открытие соединения для каждого пользователя может оказаться невозможным в общедоступном интернет-приложении, где количество одновременных пользователей может быть очень большим. Соответственно, разработчики часто хотят разделить «пул» открытых подключений между всеми текущими пользователями приложения. Количество пользователей, фактически выполняющих запрос в любой момент времени, обычно составляет очень небольшой процент от общего числа активных пользователей, и только во время обработки запроса требуется подключение к базе данных. Само приложение входит в СУБД и самостоятельно обрабатывает любые проблемы с учетными записями пользователей.

Насколько они эффективны? Зависит от реализации. Обычно я ожидаю, что пул будет создавать соединения либо при запуске, либо по запросу. Для первого соединения потребуется реальное соединение с базой данных, а затем, когда вы запрашиваете соединение, вам предоставляется существующее соединение в пуле. Таким образом, первый запрос на подключение займет больше всего времени, а потом вы просто извлекаете объекты из коллекции (очень быстро).

Создание соединений с базами данных — очень затратная операция. Пулы соединений — это экземпляры соединений с базой данных, которые создаются и кэшируются. Каждый раз, когда требуется новое подключение к базе данных, вместо создания нового подключения используется одно из пула. Некоторые платформы, такие как .NET + SQL Server, используют пулы соединений по умолчанию (вам не нужно создавать свои собственные). Таким образом, они в основном повышают производительность, экономя время на создание новых соединений каждый раз.

Используя пул соединений, вы экономите время при каждом доступе, поскольку соединение уже установлено.

Более того, по крайней мере, в Oracle вы сохраняете скомпилированную инструкцию, связанную с соединением, поэтому повторное выполнение одной и той же инструкции SQL выполняется еще быстрее.

(см. PreparedStatement, если вы используете Java/JDBC)

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

Взгляните на BoneCP (http://jolbox.com) в разделе тестов, чтобы узнать некоторые цифры. Помните, что подготовленные состояния и т. д. привязаны к соединению, поэтому вам нужно будет готовить их снова и снова, если вы имеете дело с соединениями самостоятельно (пул соединений также кэширует их для вас).

Мое лучшее решение на данный момент: используйте lazyDataSource, который дает вам соединение только тогда, когда оно вам действительно нужно (т.е. не вслепую - если данные могут поступать из кеша, вы можете избежать попадания в базу данных)

Создание пула соединений с базой данных с помощью tomcat

<сильный>1. Tomcat введите ресурс внутри: conf/context.xml

Поместите записи ресурсов в файл context.xml:

<!-- jdbc/jndiName jndi --> 
<Resource name="jdbc/jndiName" auth="Container" type="javax.sql.DataSource" initialSize="1" maxActive="100" maxIdle="30" maxWait="10000" username="enter username" password="enter password" driverClassName="diver name" url="jdbc database url"/>

<сильный>2. создайте класс, который создаст пул соединений

public class MyConnectionFactory {
    private static String module = "[ QuoteConnectionFactory ]";
    private static QuoteConnectionFactory connectionFactory;

    protected QuoteConnectionFactory() {
    }

    /**
     *
     * @return=>getInstance() is a static method which will return the instance
     *                        of its own class
     */
    public static QuoteConnectionFactory getInstance() {
        if (connectionFactory == null)
            connectionFactory = new QuoteConnectionFactory();
        return connectionFactory;
    }

    /**
     *
     * @param jndiName

     */
    public Connection getConnection(String jndiName) {
        System.out.println("jndiName=======" + jndiName);
        Connection conn = null;
        InitialContext cxt = null;
        DataSource dataSource = null;
        try {
            cxt = new InitialContext();
            Context envContext  = (Context)cxt.lookup("java:/comp/env");
            dataSource = (DataSource)envContext.lookup(jndiName);
        } catch (NamingException e) {

        } catch (Exception e) {

        }

        if (dataSource == null) {

            try {
                conn = dataSource.getConnection();
            } catch (Exception e) {

            }

            System.out.println("connection===================" + conn);
            return conn;
        }
    }

<сильный>3. редактировать файл web.xml

<resource-ref>
    <description>DB Connection</description>
    <res-ref-name>jdbc/jndiName</res-ref-name>
    <res-type>javax.sql.DataSource</res-type>
    <res-auth>Container</res-auth>
</resource-ref>

<сильный>4. Использовать в коде

Connection con= QuoteConnectionFactory.getInstance(). getConnection("jndiName");

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

Если вы собираетесь выполнить один очень простой запрос, то подключение, вероятно, займет столько же (или больше), чем запрос.

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

Если вы планируете выполнить, скажем, 100 запросов или несколько действительно медленных запросов, то время соединения становится незначительным.

В общем, я бы сказал, каждый раз открывайте новое соединение, пока вы не продемонстрируете, что это реальная проблема с производительностью. Использование пула соединений может привести к ОШИБКАМ, которые нам не нравятся:

• Состояние подключения не было ПОЛНОСТЬЮ сброшено после предыдущего использования в пуле, поэтому некоторое состояние задерживается и создает неожиданное поведение, приводящее к ошибке
• Соединение было закрыто каким-либо образом (возможно, из-за тайм-аута брандмауэра с отслеживанием состояния), который не может быть обнаружен, поэтому приложение пытается использовать закрытое соединение, что приводит к длительной задержке или сбою.