Пул соединений HikariPC не разделяет пул соединений между клиентами?

#java #oracle

Вопрос:

Я использую пул соединений API HikariPC с JDBC в своем настольном приложении. Пул соединений устанавливается идеально с максимальным размером пула 10, и в базе данных oracle создается сеанс 10. Проблема в том, что когда каждый отдельный клиент запускает сеанс приложения 10, созданный в базе данных, и он не использует пул общих подключений, который уже создан. вместо этого он создает для каждого нового подключенного клиента 10 сеансов в базе данных. Вот мой код:

  public class ConnectionPool {

private static Properties properties = null;
private static HikariDataSource dataSource;

static {
    try {
        dataSource = new HikariDataSource();
        dataSource.setDriverClassName("oracle.jdbc.OracleDriver");

        dataSource.setJdbcUrl("jdbc:oracle:thin:@//128.1.10.150:1521/orcl");
        dataSource.setUsername("scott");
        dataSource.setPassword("faizi");

        dataSource.setMinimumIdle(100);
        dataSource.setMaximumPoolSize(10);//The maximum number of connections, idle or busy, that can be present in the pool.
        dataSource.setAutoCommit(false);
        dataSource.setLoginTimeout(3);

    } catch (SQLException ex) {
        Logger.getLogger(ConnectionPool.class.getName()).log(Level.SEVERE, null, ex);
    }
}

public static DataSource getDataSource() {
    return dataSource;
}

}
 

И когда я вызываю класс подключения :

 public void addCountryToObservableList() {
    String sql = "select * from country";
    try (Connection conn =ConnectionPool.getDataSource().getConnecton();
        PreparedStatement pst = conn.prepareStatement(sql); ResultSet rs = pst.executeQuery()) {
        while (rs.next()) {
            countries.add(new Country(rs.getInt("code"), rs.getString("country")));
        }
    } catch (SQLException ex) {
        ShowErroMessage(ex, "addCountryToObservableList() methods");
    }
 }
 

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

Комментарии:

1. Пул соединений волшебным образом не разделяет соединения между клиентами. Он совместно использует соединения внутри приложения .

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

Ответ №1:

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

Причина объединения коллекций в том, что установление соединения обходится дорого, поэтому вместо того, чтобы создавать/закрывать новое соединение каждый раз, когда оно вам нужно, пул connectin «предоставляет» вам уже живое соединение, что ускоряет всю обработку. Но это происходит только внутри приложения и по всему миру

Комментарии:

1. если для каждого клиентского соединения установлен пул, то база данных зависает и производительность снижается.

2. Правильно, но это не имеет значения, используете вы пул соединений или нет. В вашем случае удаление пула соединений немного замедлит работу ваших клиентских приложений, но та же проблема возникнет, когда вы получите пользователей x10. В большинстве случаев вы подключаетесь к базе данных не напрямую, а через свой API приложения, который находится на стороне сервера. Затем только сервер устанавливает соединение с базой данных — и проблема устранена. На самом деле именно так вы можете установить «глобальное объединение».

3. Если вы не используете многопоточность и одновременно не выполняете операции более чем с 1 дБ, либо отправьте CP по электронной почте, либо установите максимальное значение 1 соединение с некоторым временем простоя.

4. @Antoniosss удаление бассейна — плохая идея. Такие вещи, как простое тестирование, обновление соединений, управление ресурсами и предотвращение/обнаружение утечек — это не тривиальные проблемы. Использование необработанного JDBC-плохая идея.

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