Гость
Форумы / Java [игнор отключен] [закрыт для гостей] / Hikari connection pool singleton factory / 24 сообщений из 24, страница 1 из 1
04.07.2019, 09:47
    #39833676
Molasar
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
Всем привет!

Нужна реализация Hikari connection pool singleton factory с настройкой пула через run-time HikariConfig, т.е. зашитые параметры в блоке static или jndi ресурсы не подойдут.

Приведенный ниже код работает, но не эффективен, т.к. synchronized нужен для первого обращения, после он будет только тормозить процесс.

Какой другой синглтон лучше использовать в этом случае?

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
public class HikariConectionFactory {
      
    private static HikariDataSource hikariDataSource = null;

    private HikariConectionFactory() {
    }

    public static synchronized Connection getConnection(HikariConfig hikariConfig)
            throws SQLException, ClassNotFoundException {
        if (hikariDataSource == null) {
            hikariDataSource = new HikariDataSource(hikariConfig);
        }
        return hikariDataSource.getConnection();
    }
}
...
Рейтинг: 0 / 0
04.07.2019, 09:56
    #39833684
Molasar
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
Есть вариант с Double Checked Locking & volatile, но читал что этот вариант будет тормозить на многопроцессорных серверах.
...
Рейтинг: 0 / 0
04.07.2019, 10:18
    #39833699
PetroNotC Sharp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
Molasar,
Если крайне нужна скорость, то создавай коннект при старте потока внутри потока. Без пула.
Тогда никаких ограничений вообще не будет.
Имхо
...
Рейтинг: 0 / 0
04.07.2019, 10:35
    #39833709
Molasar
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
C пулом Hikari получается быстрее.
Я создаю пул потоков, каждый из которых хватает connection из пула Hikari и пишет в базу.
Но для этого требуется настроить пул.
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
public class FlushObjectToDB implements Runnable {
    
    ...
    @Override
    public void run() {
        try (Connection connection = HikariConectionFactory.getConnection()) {
            ...
        } catch (SQLException ex) {
            throw new RuntimeException(exceptionFailedGetHikariConnection, ex);
        }
    }
}



PetroNotC SharpMolasar,
Если крайне нужна скорость, то создавай коннект при старте потока внутри потока. Без пула.
Тогда никаких ограничений вообще не будет.
Имхо
...
Рейтинг: 0 / 0
04.07.2019, 10:55
    #39833724
Мозговой_слизень
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
ну... что тут можно подсказать))) ты сам все написал вроде правильно.

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
public class HikariConectionFactory {
      
private static volatile HikariDataSource hikariDataSource;
private HikariConectionFactory() {    }

 if(hikariDataSource== null) 
    {        
      synchronized(HikariConectionFactory.class) 
       {            
         if(hikariDataSource== null)  
          {               
           hikariDataSource= new HikariConectionFactory ();
           } 
      } 
   } 
return hikariDataSource.getConnection();


}



ИМХО на многопроцессорных машинах усё работать должно так же как на однопроцессорной. Ибо кол-во потоков и так будет многократно превышать кол-во процессоров. То есть заданий 1000 а процессоров 8. То же самое как если бы заданий было 200 а процессор 1
...
Рейтинг: 0 / 0
04.07.2019, 11:04
    #39833728
PetroNotC Sharp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
MolasarC пулом Hikari получается быстрее.обоснуй.
Чтобы пул не ждал, MAX в пуле коннектов не менее потоков.
Если потоков 1000, и MAX 500 то будет ожидание.
Это суть пулов вообще. Они не для твоего проекта.
...
Рейтинг: 0 / 0
04.07.2019, 11:10
    #39833732
Мозговой_слизень
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
Вернее так:

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
public class HikariConectionFactory {
      
private static volatile HikariDataSource hikariDataSource;
private HikariConectionFactory() {    }

    public static Connection getInstance(HikariConfig hikariConfig)
    {

        if (hikariDataSource == null)
        {
            synchronized (HikariConectionFactory.class)
            {
                if (hikariDataSource == null)
                {
                    hikariDataSource = new HikariConectionFactory();
                }
            }
        }
        return hikariDataSource.getConnection();

    }

}
...
Рейтинг: 0 / 0
04.07.2019, 11:23
    #39833738
Molasar
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
Это вариант - Double Checked Locking & volatile, но читал что этот вариант будет тормозить на многопроцессорных серверах.
Чтобы не тормозило нужно ввести локальную переменную:
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
public class HikariConectionFactoryDoubleCheck {

    private static volatile HikariDataSource hikariDataSource;

    public static synchronized Connection getConnection(
            HikariConfig hikariConfig)
            throws SQLException, ClassNotFoundException {
        HikariDataSource localHikariDataSource = hikariDataSource;
        
        if (localHikariDataSource == null) {
            synchronized (HikariConectionFactoryDoubleCheck.class) {
                localHikariDataSource = hikariDataSource;
                if (localHikariDataSource == null) {
                    hikariDataSource = localHikariDataSource 
                            = new HikariDataSource(hikariConfig);
                }
            }
        }
        return localHikariDataSource.getConnection();
    }
    
}


Мозговой_слизеньВернее так:

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
public class HikariConectionFactory {
      
private static volatile HikariDataSource hikariDataSource;
private HikariConectionFactory() {    }

    public static Connection getInstance(HikariConfig hikariConfig)
    {

        if (hikariDataSource == null)
        {
            synchronized (HikariConectionFactory.class)
            {
                if (hikariDataSource == null)
                {
                    hikariDataSource = new HikariConectionFactory();
                }
            }
        }
        return hikariDataSource.getConnection();

    }

}
...
Рейтинг: 0 / 0
04.07.2019, 11:42
    #39833749
Мозговой_слизень
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
Да как удобней. Мне еще не понятно почему это будет тормозить. Для проверки этого утверждения неплохо было бы как-то измерить скорость. И "тормоза" понятие относительное. Где-то нужна скорость, где-то этим можно пренебречь, от проекта зависит. Метод написан корректно (по крайней мере для 8-ой джавы). А дальше уже сколько хотите столько и придумывайте как это улучшить. Если это вообще возможно.
...
Рейтинг: 0 / 0
04.07.2019, 11:57
    #39833754
Molasar
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
Многопроцессорные сервера будут больше тратить времени на доступ к переменной volatile, чем на доступ с локальной переменной.
У меня сейчас нет возможности протестировать это на таком сервере.
Мозговой_слизеньДа как удобней. Мне еще не понятно почему это будет тормозить. Для проверки этого утверждения неплохо было бы как-то измерить скорость. И "тормоза" понятие относительное. Где-то нужна скорость, где-то этим можно пренебречь, от проекта зависит. Метод написан корректно (по крайней мере для 8-ой джавы). А дальше уже сколько хотите столько и придумывайте как это улучшить. Если это вообще возможно.
...
Рейтинг: 0 / 0
04.07.2019, 12:14
    #39833758
забыл ник
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
public class HikariConectionFactoryDoubleCheck {

    private static volatile HikariDataSource hikariDataSource; ----- зачем здесь volatile, если единожды установившись он не меняется

    public static synchronized Connection getConnection( -------------- первая точка синхронизации
            HikariConfig hikariConfig)
            throws SQLException, ClassNotFoundException {
        HikariDataSource localHikariDataSource = hikariDataSource;
        
        if (localHikariDataSource == null) {
            synchronized (HikariConectionFactoryDoubleCheck.class) { -------- wtf??? вторая точка синхронизации
                localHikariDataSource = hikariDataSource;
                if (localHikariDataSource == null) {
                    hikariDataSource = localHikariDataSource 
                            = new HikariDataSource(hikariConfig);
                }
            }
        }
        return localHikariDataSource.getConnection();
    }
    
}



Если сказать коротко, то это фиаско, полный треш. Вместо вполне нормального
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
public class HikariConectionFactory {
      
    private static HikariDataSource hikariDataSource = null;

    private HikariConectionFactory() {
    }

    public static synchronized Connection getConnection(HikariConfig hikariConfig)
            throws SQLException, ClassNotFoundException {
        if (hikariDataSource == null) {
            hikariDataSource = new HikariDataSource(hikariConfig);
        }
        return hikariDataSource.getConnection();
    }
}



вот этот вот треш с двумя синхронайзед блоками и волатайл на горячую переменную? И это предполагается быстрее? Пздц. И весь рефакторинг основан на том что ты прочитал какую то статью где говорят что синхронайзед это медленно?
Не принимай на личный счет, но с такими познаниями писать многопоточку это ужас, и вдвойне ужас что кто-то скидывает на тебя такие задачи. Я понимаю что время-деньги и программа нужна чейчас, но я даже у индусов в последнее время такого го..а не вижу.
Самое приксорбное что такое разгильдяйство везде.

Совет 1 - Читай не стать и и бложики, а хорошие проверенные книги. В твоем случае Java Concurrency in Action просто must-have, читать раза 3. Потом можно прочитать Art Of Multiprocessor programming, раз 5. В перерывах смотреть все видосы Шипилева и Куксенко, можно читать их статьи тоже. Потом можно приступать к промышленному кодированию многопоточки. Да это долго, но пока ты этого не сделаешь ты будешь плавать в потемках и имплементить поделки методом ненаучного тыка

Сщвет 2 - Пока ты работаешь над советом номер 1, старайся не "умничать" - 100% перехитришь сам себя, как в этом случае. Не делай ничего если не понимаешь последствий. В твоем случае самый первый вариант оптимальный. Вот начнет тормозить, тогда и подумаешь как исправить. С вероятностью 99.9999% тормоза будут в другом месте.

Следовать или нет советам - это дело конечно сугубо твое, но я писал их не за тем чтобы загнобить или затроллить
...
Рейтинг: 0 / 0
04.07.2019, 12:17
    #39833761
chpasha
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
MolasarУ меня сейчас нет возможности протестировать это на таком сервере
а мозг у тебя есть чтобы прикинуть о каких временных затратах может идти речь? Особенно по сравнению с тысячами инсертов в базу, http запросами и прочим хозяйством? Я уже один раз намекнул в другом топике, что преждевременная оптимизация вредна, особенно в случае новичков. Но ты этого либо не понял либо не сделал никаких выводов.
...
Рейтинг: 0 / 0
04.07.2019, 12:25
    #39833766
PetroNotC Sharp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
chpashaMolasarУ меня сейчас нет возможности протестировать это на таком сервере
а мозг у тебя есть чтобы прикинуть о каких временных затратах может идти речь? Особенно по сравнению с тысячами инсертов в базу, http запросами и прочим хозяйством? Я уже один раз намекнул в другом топике, что преждевременная оптимизация вредна, особенно в случае новичков. Но ты этого либо не понял либо не сделал никаких выводов.+1
...
Рейтинг: 0 / 0
04.07.2019, 12:29
    #39833768
Molasar
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
Первая точка синхронизации не нужна конечно. Случайно добавил.
Про volatile может быть вы и правы. Своё мнение сложилось после прочтения статьи http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

Вообще без обид. Я всегда с большим уважением отношусь к советам и критике, на этом форуме от более просвещенных коллег.
Эти книги уже скачал) В ближайшее время буду читать.


забыл ник
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
public class HikariConectionFactoryDoubleCheck {

    private static volatile HikariDataSource hikariDataSource; ----- зачем здесь volatile, если единожды установившись он не меняется

    public static synchronized Connection getConnection( -------------- первая точка синхронизации
            HikariConfig hikariConfig)
            throws SQLException, ClassNotFoundException {
        HikariDataSource localHikariDataSource = hikariDataSource;
        
        if (localHikariDataSource == null) {
            synchronized (HikariConectionFactoryDoubleCheck.class) { -------- wtf??? вторая точка синхронизации
                localHikariDataSource = hikariDataSource;
                if (localHikariDataSource == null) {
                    hikariDataSource = localHikariDataSource 
                            = new HikariDataSource(hikariConfig);
                }
            }
        }
        return localHikariDataSource.getConnection();
    }
    
}



Если сказать коротко, то это фиаско, полный треш. Вместо вполне нормального
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
public class HikariConectionFactory {
      
    private static HikariDataSource hikariDataSource = null;

    private HikariConectionFactory() {
    }

    public static synchronized Connection getConnection(HikariConfig hikariConfig)
            throws SQLException, ClassNotFoundException {
        if (hikariDataSource == null) {
            hikariDataSource = new HikariDataSource(hikariConfig);
        }
        return hikariDataSource.getConnection();
    }
}



вот этот вот треш с двумя синхронайзед блоками и волатайл на горячую переменную? И это предполагается быстрее? Пздц. И весь рефакторинг основан на том что ты прочитал какую то статью где говорят что синхронайзед это медленно?
Не принимай на личный счет, но с такими познаниями писать многопоточку это ужас, и вдвойне ужас что кто-то скидывает на тебя такие задачи. Я понимаю что время-деньги и программа нужна чейчас, но я даже у индусов в последнее время такого го..а не вижу.
Самое приксорбное что такое разгильдяйство везде.

Совет 1 - Читай не стать и и бложики, а хорошие проверенные книги. В твоем случае Java Concurrency in Action просто must-have, читать раза 3. Потом можно прочитать Art Of Multiprocessor programming, раз 5. В перерывах смотреть все видосы Шипилева и Куксенко, можно читать их статьи тоже. Потом можно приступать к промышленному кодированию многопоточки. Да это долго, но пока ты этого не сделаешь ты будешь плавать в потемках и имплементить поделки методом ненаучного тыка

Сщвет 2 - Пока ты работаешь над советом номер 1, старайся не "умничать" - 100% перехитришь сам себя, как в этом случае. Не делай ничего если не понимаешь последствий. В твоем случае самый первый вариант оптимальный. Вот начнет тормозить, тогда и подумаешь как исправить. С вероятностью 99.9999% тормоза будут в другом месте.

Следовать или нет советам - это дело конечно сугубо твое, но я писал их не за тем чтобы загнобить или затроллить
...
Рейтинг: 0 / 0
04.07.2019, 12:36
    #39833776
Molasar
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
Да, я помню твой совет. Спасибо.
Но на текущий момент я сделал свою часть проекта раньше других. Есть время поэкспериментировать над производительностью, чтобы в будущем можно было использовать. Чем это плохо?
chpashaMolasarУ меня сейчас нет возможности протестировать это на таком сервере
а мозг у тебя есть чтобы прикинуть о каких временных затратах может идти речь? Особенно по сравнению с тысячами инсертов в базу, http запросами и прочим хозяйством? Я уже один раз намекнул в другом топике, что преждевременная оптимизация вредна, особенно в случае новичков. Но ты этого либо не понял либо не сделал никаких выводов.
...
Рейтинг: 0 / 0
04.07.2019, 12:44
    #39833785
Molasar
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
Простой тест на моей клиентской машине для разных реализаций синглтона (nTimes = 100 000 000):
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
        long start = System.currentTimeMillis();
        for (int i = 0; i < nTimes; i++) {
            Connection connection
                    = HikariConectionFactorySynchronized
                            .getConnection(hikariConfig);
            connection.close();
        }
        System.out.println(nTimes 
                + " connections by Synchronized factory takes: "
                + (System.currentTimeMillis() - start));



DoubleCheck&Volatile + LocalVar: 7386 millis
DoubleCheck&Volatile: 7449 millis
Synchronized: 8585 millis

Мозговой_слизеньДа как удобней. Мне еще не понятно почему это будет тормозить. Для проверки этого утверждения неплохо было бы как-то измерить скорость. И "тормоза" понятие относительное. Где-то нужна скорость, где-то этим можно пренебречь, от проекта зависит. Метод написан корректно (по крайней мере для 8-ой джавы). А дальше уже сколько хотите столько и придумывайте как это улучшить. Если это вообще возможно.
...
Рейтинг: 0 / 0
04.07.2019, 13:14
    #39833798
PetroNotC Sharp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
MolasarПростой тест на моейа где 1000 потоков конкурирующих к пулу?
Что тестировал?
...
Рейтинг: 0 / 0
04.07.2019, 13:17
    #39833800
PetroNotC Sharp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
MolasarЧем это плохо?тем что тестировать надо то что пишешь.
Написал секцию синхронизации, и сразу тест НА ЭТУ СЕКЦИЮ. Чтобы она тормознула 999 потоков и пропустила только один.
...
Рейтинг: 0 / 0
04.07.2019, 14:02
    #39833838
Lelouch
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
Molasar,

Посмотрите вот этот доклад про JMM:
YouTube Video
...
Рейтинг: 0 / 0
04.07.2019, 14:08
    #39833844
Андрей Панфилов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
Molasar,

у вас идея изначально неверная, что размер JDBC-пула должен каким-то образом соотноситься с количеством ядер. Правильная идея: размер пула должен быть строго больше количества потоков, которые из этого пула могут тягать соединения. Почему так? Вот несколько довольно распространенных тем:
- паттерн, что мы можем из одного потока создать несколько соединений вполне нормальный: в одном месте мы что-то делаем в одной транзакции, а в другом месте мы хотим что-то сделать в другой транзакции, не закрывая первую
- поток, который взял соединение из пула может при выполнении наткнуться на критическую секцию в коде/обращение к тормозным внешним ресурсам/и пр., поэтому будет получаться, что кто-то ждет когда поток вернет соединение, а сам поток ждет чего-то другого

поэтому выставлять размер JDBC-пула меньше чем количество потоков можно только тогда, когда вы полностью контролируете весь код и всегда знаете что и где происходит, в противном случае размер JDBC-пула должен быть больше количества потоков.
...
Рейтинг: 0 / 0
04.07.2019, 14:27
    #39833856
PetroNotC Sharp
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
Андрей Панфилов,
Как всегда правы.
...
Рейтинг: 0 / 0
04.07.2019, 16:41
    #39833946
Мозговой_слизень
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
Ну то есть,как я понял, автор изначально написал нормальный код. Мы его тут немного улучшили with Double‐Checked locking, но он об этом и так догадывался.
А если не секрет, автор, ты из какого города и сколько ЗП?
...
Рейтинг: 0 / 0
04.07.2019, 16:41
    #39833948
Мозговой_слизень
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
Мозговой_слизеньНу то есть,как я понял, автор изначально написал нормальный код. Мы его тут немного улучшили with Double‐Checked locking, но он об этом и так догадывался.
А если не секрет, автор, ты из какого города и сколько ЗП?
блин, там просто смайлик должен быть обычный
...
Рейтинг: 0 / 0
04.07.2019, 17:36
    #39833981
забыл ник
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Hikari connection pool singleton factory
Мозговой_слизень, Нормальным рещением проблемы было бы инициализировать DataSource в точке старта приложения и передавать его в конструктор ConnectionFactory, HikariDataSource hikariDataSource --- сделать final и забыть о синхронизации насовсем.
А в данном случае была решена непонятная проблема по-любому не лучшим, но сносным способом.
...
Рейтинг: 0 / 0
Форумы / Java [игнор отключен] [закрыт для гостей] / Hikari connection pool singleton factory / 24 сообщений из 24, страница 1 из 1
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]