ПолучаемаяБазаСомОбъект = V8.Connect(СтрокаПодключенияКБД);
на следующий день,,,,,
...
Возможно ли один раз получив и записав СомОбъект в виде подключения к базе, в дальнейшем не тратить время на подключение, а подключаться сразу?
А если с базой есть ошибка, то по попытке это отловить и все равно выйдет быстрее.
Почему никто так не делает?
СохранитьЗначение(ПолучаемаяБазаСомОбъект, СтрокаПараметраПодключения);
...на следующий день,,,,,
...
ПолучаемаяБазаСомОбъект = ВосстановитьЗначение(СтрокаПараметраПодключения);
Возможно ли один раз получив и записав СомОбъект в виде подключения к базе, в дальнейшем не тратить время на подключение, а подключаться сразу?
А если с базой есть ошибка, то по попытке это отловить и все равно выйдет быстрее.
Почему никто так не делает?
Найденные решения
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Никто так не делает видимо потому, что анабиоз в мире компьютеров еще не изобрели. Есть гибернация, спящий режим. Но это на уровне операционных систем. Базу ведь вы замораживать не станете до следующего утра?
(2) а зачем базу замораживать?
Ведь комообъект это не база, а доступ к ней. Не закачено же в него все содержимое БД.
Другое дело, что комообъект как значение не сохраниться наверное, его можно только временно в хранилище помещать.
Но, вот если бы была такая возможность, то было бы очень интересно проверить как будет работать.
Неужели нет такой возможности?
Может есть не временное, а постоянное хранилище?
Ведь комообъект это не база, а доступ к ней. Не закачено же в него все содержимое БД.
Другое дело, что комообъект как значение не сохраниться наверное, его можно только временно в хранилище помещать.
Но, вот если бы была такая возможность, то было бы очень интересно проверить как будет работать.
Неужели нет такой возможности?
Может есть не временное, а постоянное хранилище?
(4) Около сорока баз в которых ведется бухучет.
Одна общая УПП в которой ведется управленческий учет. Подключаемся к каждой БД через обработку от УПП (логины, пароли, явки) записаны открыто в таблице, галочками выбираем что грузим.
Грузим естественно с проблемами, которые выясняются по ходу дела. Обработка ловит незаполненные документы, неправильно заполненные и подобные эвристики.
Потом исправленное грузим заново, смотрим бьют ли остатки и тп. Иногда приходится искать исправления внесенные бухгалтерами в прошлом (иначе не бъет), а это все подключения.
На подключение к БД тратится секунд 15. Что в итоге, неплохо крадет время.
В рамках ускорения решил хранить подключения в виде СОМОбъектов к БД.
Одна общая УПП в которой ведется управленческий учет. Подключаемся к каждой БД через обработку от УПП (логины, пароли, явки) записаны открыто в таблице, галочками выбираем что грузим.
Грузим естественно с проблемами, которые выясняются по ходу дела. Обработка ловит незаполненные документы, неправильно заполненные и подобные эвристики.
Потом исправленное грузим заново, смотрим бьют ли остатки и тп. Иногда приходится искать исправления внесенные бухгалтерами в прошлом (иначе не бъет), а это все подключения.
На подключение к БД тратится секунд 15. Что в итоге, неплохо крадет время.
В рамках ускорения решил хранить подключения в виде СОМОбъектов к БД.
(5)Что то мне подсказывает, что не в ту степь вы полезли. "незаполненные документы," это отсекается просто, "неправильно заполненные и подобные эвристики" это по рукам кто заполняет, зачем выполнять двойную работу, может тогда сразу бить в УПП и не заморачиваться с обменами?
(5) мдя... Архитектура не самая лучшая... А почему нельзя выявить четкие регламенты что, куда и во-сколько загружать? Затем перекинуть проблемы обмена на регламентные задания. Некорректно заполненные документы отсекать ещё на этапе чтения (в удаленной базе, типа по таблице соответствий реквизитов).
(6) Документы проведены, проводки есть. Обычно такие ошибки при закрытии месяца замечают, тут их ловим раньше.
Понятно, что бухгалтера и исправляют и тут же учатся, время то от ошибки прошло мало день, два. Это тоже плюс.
УПП возникло позже, да и тормозить тогда зверский будет - все в одной БД сидят, а так распределено на разных серверах, иногда в файловых вариантах БД.
Понятно, что бухгалтера и исправляют и тут же учатся, время то от ошибки прошло мало день, два. Это тоже плюс.
УПП возникло позже, да и тормозить тогда зверский будет - все в одной БД сидят, а так распределено на разных серверах, иногда в файловых вариантах БД.
Из своего опыта не видел еще ни одной организации где 50 и более человек не тормозили. Ни одного случая.
Возможно, что все делают какую-то ошибку в настройках БД 1С. Но не знаю.
Возможно, что все делают какую-то ошибку в настройках БД 1С. Но не знаю.
Пока неясно следующее, можно ли сохранять СОМОбъекты хотябы во временное хранилище, уже реализовал, работает.
Но не ясно с ошибками или нет. Скажем если поработать СОМОбъектом минут через 15 после его создания, то будет он работать или нет, а если будет то правильно ли?
Но не ясно с ошибками или нет. Скажем если поработать СОМОбъектом минут через 15 после его создания, то будет он работать или нет, а если будет то правильно ли?
(15) Речь о негарантированном времени жизни любого объекта во временном хранилище, если временное хранилище не имеет привязок ко времени жизни формы, например.
По сабжу: сериализовать подключение, как и любое мутабельное значение ессно нельзя. Но можно удерживать на время сеанса. На стороне сервера для этого можно задействовать модуль с повторным использованием возвращаемых значений. Сделать функцию, которая принимает строку подключения, а возвращает объект подключения. При повторных обращениях будет возвращаться уже созданное подключение.
По сабжу: сериализовать подключение, как и любое мутабельное значение ессно нельзя. Но можно удерживать на время сеанса. На стороне сервера для этого можно задействовать модуль с повторным использованием возвращаемых значений. Сделать функцию, которая принимает строку подключения, а возвращает объект подключения. При повторных обращениях будет возвращаться уже созданное подключение.
(17) "Руководство разработчика":
"При получении на сервере значения из временного хранилища следует учитывать то, что оно получается по ссылке. В действительности, ссылка эта указывает на значение, которое хранится в кеше. В течение 20 минут, с момента помещения в хранилище или же с момента последнего обращения, значение сохранится в кеше, а затем записывается на диск и из кеша удаляется. При следующем обращении значение загружается с диска и снова помещается в кеш".
Соответственно, если во временном хранилище мутабельное значение, то при попытке записи его на диск оно будет утеряно. С сериализуемыми данными никаких проблем не будет.
"При получении на сервере значения из временного хранилища следует учитывать то, что оно получается по ссылке. В действительности, ссылка эта указывает на значение, которое хранится в кеше. В течение 20 минут, с момента помещения в хранилище или же с момента последнего обращения, значение сохранится в кеше, а затем записывается на диск и из кеша удаляется. При следующем обращении значение загружается с диска и снова помещается в кеш".
Соответственно, если во временном хранилище мутабельное значение, то при попытке записи его на диск оно будет утеряно. С сериализуемыми данными никаких проблем не будет.
(17)
Все нормально будет работать, идентификатор не привязан к форме.
А уничтожаются только aplication
Так что похоже будет жить долго.
=========================================================
Соответственно возникает актуальный вопрос о том, чтобы хранить подключения к БД ВПостоянномХранилище - есть такое?
Или выгружать его в файл, а потом загружать.
Неужели невозможно?
Все нормально будет работать, идентификатор не привязан к форме.
А уничтожаются только aplication
У меня же объект
V8 = Новый COMОбъект("V83.COMConnector");
Иначе
V8 = Новый COMОбъект("V82.COMConnector");
Так что похоже будет жить долго.
=========================================================
Соответственно возникает актуальный вопрос о том, чтобы хранить подключения к БД ВПостоянномХранилище - есть такое?
Или выгружать его в файл, а потом загружать.
Неужели невозможно?
"Почему никто так не делает?" - потому что официальная документация не даёт на этот счет никаких гарантий, а использование только в очень редких задачах может дать прирост к скорости работы.
Выявлен минус хранения СОМ во временном хранилище.
Каждое такое СОМ требует лицензии, 40 баз - 40 лицензий занято.
Сохраненное во временной хранилище СОМподключение не исчезает и видно на сервере.
Каждое такое СОМ требует лицензии, 40 баз - 40 лицензий занято.
Сохраненное во временной хранилище СОМподключение не исчезает и видно на сервере.
(28) Судя по всему, ты так ничего и не понял. Временное хранилище тут непричем. COMОбъект невозможно записать. Сохраняя его во временное хранилище ты просто удерживаешь на него ссылку в памяти сервера (держишь само соединение). Как только кэш временного хранилища сбросится на диск, COMОбъект уничтожится. Костыль из (17) просто не дает кэшу сбрасываться на диск и соединение продолжает удерживаться. Или ты миришься с накладными расходами на установку соединения, или ты удерживаешь соединение со всеми вытекающими. Третьего не дано.
(31) В эпоху аппаратных ключей так и было. Локальная программная лицензия, которая привязывается к железу пользовательского компа, тоже работает так.
Но программные лицензии устанавливаемые на сервер раздаются сервером приложений "на соединение" и пользователь работающий с несколькими базами жрет несколько лицензий.
Но программные лицензии устанавливаемые на сервер раздаются сервером приложений "на соединение" и пользователь работающий с несколькими базами жрет несколько лицензий.
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот