Как, я думаю, вы уже знаете для работы с PostgreSQL сначала необходимо установить соединение с базой данных, затем используя данное соединение можно отправлять запросы. До меня уже была написана программа, в которой использовалось несколько потоков, в каждом из которых создавалось такое соединение, записывались данные в базу и соединение закрывалось. Эти потоки были итерационные в результате чего вызывались очень много раз. Но постоянное соединение в каждом из них и разъединение расточительство. В итоге руководитель поручил мне во-первых проверить возможно ли "это" и если возможно, то программу переписать.
Что именно нужно? Переписать программу так чтобы в главном потоке программы мы создавали одно подключение к бд и в последствии передавали его параметры во все потоки, где используя его, заносили данные в базу. Закрывать соединение с базой нужно уже после выполнения всех потоков.
Скажите! Это хотя бы возможно? Потому как мой руководитель сказал, что он слышал о том что эту возможность добавили в версии 8.3, но он не уверен. Вот и дал поручение мне проверить. Я подтверждения его слов в интернете пока так и не нашёл.
Ну и если это возможно, не могли бы вы привести самый простенький пример такого кода на C++, Java или Delphi ?
Не уверен что то что нужно,
Не уверен что то что нужно, зависит от используемой в программе технологии, но как вариант, в ADO TADOConection есть свойство ConnectionObject: _Connection, которое используеться для привязки компонента к уже открытому соединению. Может быть попробовать поискать в этом направлении.
Я бы попробовал решить
Я бы попробовал решить проблему по-другому. Написал бы application-сервер, который бы собственно и общался с БД через одно постоянно-открытое соединение. А программа работала бы уже не с БД, а с application-сервером. Хотя конечно, многое зависит от специфики вашего приложения.
Спасибо. Как вариант
Спасибо. Как вариант подойдёт.
Application-сервер может при
Application-сервер может при грамотном использовании ещё и существенно разгрузить сервер БД, например путём создания промежуточного кэширования запросов. Например, если есть какой-либо отчёт, который часто необходим начальству, но который генерируется раз в сутки (по данным за прошедший день), то достаточно его один раз закэшировать на application-сервере и выдавать без перегенерации и нагрузки на сервер БД.
Ещё одно преимущество applicatiion-сервер - это возможность оставить реализацию взаимодействия с БД за границей приложения. Т.е. приложение может общаться с application-сервером с помощью своего высокоуровневого API, который не будет зависеть от того какая БД используется application-сервером.
Спасибо конечно, но не могли
Спасибо конечно, но не могли бы Вы более подробно описать по какому алгоритму должно работать аpplication-серверное приложение и каким образом оно будет взаимодействовать с моим? Ну то есть как оно будет держать постоянное открытое соединение и как будет выполнять запросы моего приложения?
Если только совсем на
Если только совсем на пальцах, потому как слишком много писать.
1. Делаете демона, который при запуске открывает соединение с БД и скажем сам висит на 9000 порту, ожидая соединений от клиентов.
2. Клиент подключается к демону, и выдаёт ему скажем команду: "SHOW REPORT1".
3. На уровне вашего демона известно, что при получении команды SHOW REPORT1 необходимо выполнить к базе запрос типа: SELECT .... с кучей JOIN, сортировками, группировками и прочее с ограничением по дате за вчерашний день. Но перед этим надо посмотреть - может уже такую команду выполняли ранее и результат этого запроса уже лежит в файле кэша. Если нет, то делаем запрос к БД и одаём результаты (в каком виде решать вам) клиенту, сохранив их в файле кэша.
Разумеется подключений от клиентов может быть несколько, но соединение с БД будет по прежнему одно. В общем можно кучу вещей организовать умных, исходя из бизнес логики. Например, если один из клиентов выполняет скажем команду UPDATE SELL DATA, которая предусматривает сложные обновления таблиц, в момент которых на запись туда лезть никто не должен, то демон может либо обламывать остальных клиентов с операциями записи, либо ставить их в очередь на ожидание окончания команды UPDATE.
Опять же разумеется, что как перечень команд, так и формат обмена сервера приложений (демона) с клиентами вы вольны выбирать сами. Также как потом изменять алгоритм работы тех или иных команд внутри сервера приложений, не трогая при этом клиентские программы - они об этом не узнают, если формат входных/выходных данных не изменится.
Спасибо.
Спасибо.