Одно длинное соединение или несколько коротких соединений с базой данных? - PullRequest
0 голосов
/ 16 мая 2011

В настоящее время я пишу службу Windows, которая будет работать на Windows Server 2008. Мы с моим коллегой обсуждали один конкретный момент.Подключение к базе данных.

Мы оба думаем по-разному, и мы хотели бы узнать ваше мнение об этом.В основном служба запускает поток, который отправляет запрос в базу данных для проверки строк, имеющих определенный статус (например, ST005).Все строки с таким статусом будут возвращены.Полученные нами данные будут обработаны, а строки будут обновлены в конце.

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

У нас есть классы: контроллер, DAO и класс базы данных.

Путь № 1:

Контроллер создает класс DAO для обработки запроса.Этот класс DAO создает оператор sql со своими параметрами, а затем создает класс базы данных, который открывает соединение, выполняет запрос, возвращает набор результатов и затем закрывает соединение.

Таким образом, будет новое соединение каждый раз запрашивается запрос или обновление.

Путь № 2:

Контроллер создает класс базы данных (класс базы данных теперь предоставляется сдва новых метода, connect () и disconnect (). Затем контроллер вызывает оператор connect (), создает класс DAO и предоставляет класс базы данных в качестве параметра для конструктора класса DB. Класс DAO создает инструкцию sql с помощьюего параметры и затем обрабатывает данные.

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

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

С уважением, Флорис

1 Ответ

3 голосов
/ 16 мая 2011

Используйте пул соединений, который почти наверняка предоставлен вашим поставщиком СУБД, и позвольте ему определить лучшую стратегию. Заканчивает обсуждение.

...