Попытка выяснить, как управлять / использовать долгоживущие соединения с БД. У меня слишком мало такого опыта, так как я использовал БД только в небольших системах (до 150 одновременных пользователей, каждый из которых имел свой собственный пользователь БД / проход, поэтому в любое время было до 150 долгоживущих подключений к БД. ) или веб-страницы (каждый запрос страницы имеет свое собственное соединение с БД, которое длится менее секунды, поэтому число одновременных обращений к БД невелико).
На этот раз будет Java-сервер и Flash-клиент. Java подключается к PostgreSQL. Ожидается, что соединения будут долгоживущими, то есть начнутся, когда Flash-клиент подключится к Java-серверу, и завершатся, когда Flash-клиент отключится. Было бы лучше разделить одно соединение между всеми пользователями (клиентами) или установить частное соединение для каждого клиента? Или какое-то другое решение будет лучше?
*) Одиночное / общее соединение:
- (+) плюсы
- только одно соединение с БД для всей системы
- (-) минусы:
- транзакции не могут быть использованы (например, "user1.startTransaction (); user1.updateBooks (); user2.updateBooks (); user1.rollback ();") для одного общего подключения будет выполнен откат изменений, выполненных user2)
- длинные запросы одного пользователя могут повлиять на других пользователей (хотя и не уверены в этом)
*) Личные связи:
- (+) плюсы
- нет проблем с транзакциями:)
- (-) минусы:
- может потребоваться огромное количество одновременных подключений, т. Е. Если в сети 10000 пользователей, требуется 10000 подключений к БД, что, по-видимому, слишком большое число :) Хотя я ничего не знаю об ожидаемом количестве пользователей, так как мы все еще находимся в процессе исследования и планирования.
Одним из решений было бы введение тайм-аутов, то есть, если соединение с БД не используется в течение 15/60/900 (?) Секунд, оно отключается. Когда пользователю снова нужна БД, он снова подключается. Это кажется хорошим решением для меня, но я хотел бы знать, каковы могут быть разумные ограничения для этого, например, какое может быть максимальное число одновременных подключений к БД, какое время ожидания должно использоваться и т. Д.
Другим решением будет группирование запросов на два «типа» - один тип, который может безопасно использовать одно общее долгоживущее соединение (например, «обновить пользовательский набор last_visit = now (), где id =: user_id»), а другой - тип, который нуждается в частном кратковременном соединении (например, что-то, что потенциально может выполнять тяжелую работу или использовать транзакции). Это решение не кажется мне привлекательным, хотя, если это так, я мог бы попытаться сделать это ...
Итак ... Что другие разработчики делают в таких случаях? Есть ли другие разумные решения?