Задача такая: Создать подключение к базе данных один раз за сеанс и потом его использовать в разных модулях на сервере. База отдельная, база может быть как MS SQL, так и PostgreSQL. Подскажите как такое можно реализовать?
Зачем это надо? Каждый раз создавать подключение - очень много времени занимает.

Никак.

Максимум - модуль с переиспользованием значений и проверкой/переподключением.

Только внешний источник?

Я про тот, что в метаданных определяется.

(3) Так он тоже не очень-то сохранит подключения.
Представь себе кластер из N серверов, между которыми будет бегать твой сеанс...

(0) если у тебя какое-то сом-соединение, то его можно хранить во временном хранилище. только живет оно там не долго...

> Каждый раз создавать подключение - очень много времени занимает
Пробуй указать все параметры подключения явно
- порт
- протокол
Часто при установке соединения происходит перебор всех возможных значений.

(0) Сохрани в глобальную переменную на клиенте. Как в БПО.

(8) точно, но клиент находится ХЗ где от той базы

+ (8)
Врезка в модуль управляемого приложения из БПО
"
Перем глПодключаемоеОборудование Экспорт; // для кэширования на клиенте
"

внутри глПодключаемоеОборудование могут быть и натив и КОМ подключения. И вполне себе доступны из любой клиентской части.

(9) но клиент находится ХЗ где от той базы. И что?

(0) только выносом наружу из 1С

(12)+ особенность работы сервера 1С

(10) теперь попробуй достать эту переменную из серверного модуля...

+(14) о чем пишет автор...

О! Нужно написать микросервис (обязательно на GO), который будет хранить подключение.

(16) это один из вариантов
лично я его применяю ибо он очень удобный, простой и шустрый

короче, в (6) вариант абсолютно рабочий, у меня так нативная компонента для весов сидит и доступна из любых модулей программы, но её дергать не реже чем раз в 20 мин надо, иначе сдохнет...

(18) решение очень стремное и сильно ограниченное
в случае кластера из нескольких серверов 1С или файловой упс

(0) Главное, чтобы несколько пользователей/фоновых и т.п. одновременно не начали общаться через это подключение
Как бы ему не поплохело от этого

(20) что мешает хранить адрес подключения в параметрах сеанса? тогда такой проблемы не будет...

(21) очередь как реализуешь?

(22) очередь из чего?...

(11) и доступа с клиента нет

(23) для чего
для того "чтобы несколько пользователей/фоновых и т.п. одновременно" одно подключение юзали
а очередь это дело разруливает

(25)+ в больших языках это называется пул соединений (1-много)
и пул клиентов может этот пул легко использовать не заботясь поднято ли и занято ли, просто время ответа меняется

(25) автор пишет:
"Создать подключение к базе данных один раз за сеанс и потом его использовать"

и где здесь про то, что это соединение одновременно должны пользовать несколько пользователей?...

(27) Хороший программист думает наперед и предвидит затыки

(28) ааа...

(28)+ а плохому это не надо
ему надо взять "готовый модуль" написанный хорошим и тупо его юзать
ну или слегка подучиться чтобы стать программистом получше

(30) если хороший программист, в твоем понимании, это тот, кто делает задачу не соответствующую поставленной задаче, то по-моему это не хороший программист, а чудак какой-то, который попусту тратит время и деньги клиента/работодателя...

(31) думаешь ему начальник такую задачу поставил?

(31) а вот где надо остановиться в делании задачи это уже искусство с кучей опыта
говнокод тяп ляп и ХХП вполне допустимы на разовой задаче или для MVP
если же долгоиграющий прод с вероятным превращением в легаси то решение задачи на низком уровне означает что некто уже навострил лыжи и после него хоть потоп

(33) *низком уровне = хреновом

(33)+ хотя на практике часто "давай быстрей-быстрей" и заставляют говнокодить а потом удивляются техдолгу