JDBC, почему нельзя использовать один Connection для нескольких методов в разрезе многопоточности?

Question

[Valeriy_Morozov]

Создадим переменную класса
private Connection connection;
// Ее инициализируем в конструкторе

private myManager() {
        String connectionUrl = getConnectionUrl();

        try {
            Class.forName("com.mysql.cj.jdbc.Driver");
            connection = DriverManager.getConnection(connectionUrl);

        } catch (ClassNotFoundException | SQLException e) {
            e.printStackTrace();
        }

    }

И используем его для всех CRUD операций в классе.
Я понимаю, что так плохо, но хочу понять почему именно в разрезе многопоточности
1. Что плохого произойдет если два потока одновременно обратятся к конекшену?
2. Разве у каждого из потоков не будет свой экземпляр connection, мы же не создаем его статическим? Соответственно, два потока к одному экземпляру обратиться не могут.
3. База данных же очень ограничена по количеству connection, как она работает, когда будет 100 пользователей программы ( выходит, 100 потоков со своими connection обратятся к ней ).

Я буду очень благодарен за ответы, особенно на 2 вопрос.

Comments

[Jacen11]

мы же не создаем его статическим?

DriverManager.getConnection(connectionUrl)

во первых, а что это тогда по твоему? во вторых какая разница из статик метода создаешь или нет?

Соответственно, два потока к одному экземпляру обратиться не могут.

это из чего вообще такие выводы? где связь?

[Jacen11]

почему нельзя использовать один Connection для нескольких методов

а с чего ты вообще это взял?

[Valeriy_Morozov]

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

[Valeriy_Morozov]

Jacen11,
DriverManager.getConnection(connectionUrl)
Это загрузка драйвера в оперативную память,
А насчет двух потоков и одного экземпляра -
Работу со статическими переменными в многопоточном приложении мы же синхронизируем.
я думал, что нестатическая переменная класса Connection для каждого потока будет создаваться заново, но сейчас понимаю, что это неправильно, т.к. все потоки работают с одним экземпляром класса.

[Jacen11]

Valeriy_Morozov,

connection имеет свойство закрываться спустя некоторое время

шта

connection надо закрывать каждый раз после выполнения работы метода

зачем тогда это раз по твоему оно само закрывается?

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

Работу со статическими переменными в многопоточном приложении мы же синхронизируем.

бред

почитай что такое volatile и синхронайзд

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

Answer 1

[Михаил]

1. Синхронизация между потоками. Если оба потока начнут посылать запросы в БД через один коннекшен - могут начаться спецэффекты (тут нужно курить "потокобезопасность" коннекшена)
2. Транзакции в БД. Запросы через один коннекшен будут в одной транзакции. Если для вас это ОК - то все ок. Если же разные потоки требуют разных транзакций - то придется каждому потоку выдавать свой коннекшен.
100 пользователей и 100 потоков - это слегка разные вещи. Я бы в первую очередь посмотрел сюда - по потоку на каждого пользователя для меня выглядит подозрительно. Если это веб, то у вас от каждого пользователя приходит запрос, обрабатывается, отправляется ответ. Все. Если от пользователей приходит мало запросов - это может делать и один поток. И даже в случае вебсокетов - все равно не нужно держать по потоку на пользователя.

Answer 2

[Алексей Черемисин]

Можно использовать, но нужно делать синхронизацию между разными потлками.
Проблема в том, что один поток будет ждать ответа на свой запрос, в то время, как другой поток захочет выполнить свой запрос.
Так что, если добавите синхронизацию, то можно.
Но вообще-то не нужно изобретать велосипеды, пользуйтесь пулами соединений, их есть много разных.
Например hikaricp https://habr.com/ru/post/269023/