Совместное подключение БД к частным соединениям с БД

Question

Попытка выяснить, как управлять/использовать долгоживущие соединения БД. У меня слишком мало опыта такого рода, поскольку я использовал DB только с небольшими системами (до 150 одновременных пользователей, каждый из которых имел свой собственный пользовательский интерфейс/pass, поэтому в любое время было до 150 долгоживущих соединений DB) или веб-страниц (каждый запрос страницы имеет свое собственное соединение с БД, которое длится менее секунды, поэтому количество одновременных подключений к БД не велико).

На этот раз будет сервер Java и клиент Flash. Java подключается к PostgreSQL. Ожидается, что соединения будут долговечными, т. Е. Ожидается, что они начнутся, когда клиент Flash подключится к серверу Java и завершится, когда клиент Flash отключится. Было бы лучше разделить одно соединение между всеми пользователями (клиентами) или сделать частное подключение для каждого клиента? Или какое-то другое решение было бы лучше?

*) Одноместный/общее подключение:

• (+) плюсы
  • только одно соединение DB для всей системы
• (-) минусы:
  • операции не может использоваться (например, «user1.startTransaction(); user1.updateBooks(); user2.updateBooks(); user1.rollback();» - одно общее подключение будет откатить изменения, сделанные user2)
  • длинные запросы одного пользователя может повлиять на других пользователей (не уверен в этом, хотя)

*) Частные соединения:

• (+) плюсы
  • никаких проблем с сделок :)
• (-) минусы:
  может потребоваться
  • огромное количество одновременных соединений, то есть, если есть 10000 пользователей онлайн, 10000 соединений DB требуется, который, кажется, слишком большое число :) Я не однако, известно о ожидаемом числе пользователей, поскольку мы все еще находимся в процессе исследования и планирования.

Одним из решений было бы ввести тайм-аута, то есть, если БД соединение не используется для 15/60/900 (?) Секунд, он получает отключен. Когда пользователь снова нуждается в БД, он снова подключается. Это представляется хорошим решением для меня, но я хотел бы знать, какие могут быть разумные ограничения для этого, например, какое может быть максимальное количество одновременных соединений БД, какой тайм-аут следует использовать и т. Д.

Другое решением было бы группировать запросы на два типа: один тип, который может безопасно использовать одно совместное долгоживущее соединение (например, «обновить пользовательский набор last_visit = now(), где id =: user_id»), а другой тип, которому требуется частное короткоживущее соединение (например, что-то, что может потенциально совершить тяжелую работу или использовать транзакции). Это решение, похоже, не привлекает меня, хотя, если это так, то я могу попытаться это сделать ...

Итак ...Что делают другие разработчики в таких случаях? Существуют ли другие разумные решения?

Answer 1

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

Позвольте контейнеру управлять бассейном для вас - вот для чего он нужен.

Answer 2

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

Вам определенно нужен пул соединений. Если приложение запущено внутри сервера приложений, используйте пул контейнеров. Или вы можете использовать библиотеку пула соединений, например c3p0.