Добрый вечер. Написал скрипт и инициализировал таймер на ubuntu server, для автоматического принудительного завершения сеансов пользователей с помощью "rac session terminate".
Насколько это безопасно для целостности базы данных? Например, если вдруг-кто будет работать в базе в момент принудительного завершения сеанса?

(0) С вероятностью 72.4% безопасно, но все зависит от марки блока питания установленного в сервере

Что ты хочешь услышать? Любое прерывание опасно для целостности, тем более если в момент прерывания идет запись в базу (например проведение документом, или обмены).

Это как в DT выгружать. Ктото 15 лет в dt выгружает и у него ни разу не было сбоя. А у котого раз в месяц стабильно получается битая база в dt. Вот как рассчитать насколько безопасно выгружать в dt?
Вот тут примерно такой же процент на уровне - как повезет.

На моей практике, во времена 8.0 могли слететь итоги (пару раз такое ловил). Но в те времена и платформа вела себя нестабильно, при больших объектах могла не формировать проводки у проведенных документов.
Сейчас на 8.3 ниразу не видел что бы кто-то жаловался что после того как принудительно закрыли 1С - что от сломалось. Но в теории есть ненулевой шанс, что что-то пойдет не так

(0) про транзакции слышал?

(2) на терминале блокирую вход, через какое-то время дроп. По идее, кроме как групповое проведение за двести лет, ниче не должно быть в открытой транзакции. Кроме как завершение сеанса безопаснее ничего не вижу. Самого агента рубить бред, через обработку - по сути, тоже обращение к ras. А зависшие сеансы мне не нужны.

(4) Ну бухи любят на ночь ставить перепроводку минимум за 3 месяца.

А в типовых БСП есть же подсистема «Завершение работы пользователей». почему её не использовать?

(5) Если вы про "АдминистрированиеКластераRAS.УдалитьСеансыИнформационнойБазы(АдминКластера, АдминИБ,);"
То там, тот же алгоритм управления кластером через RAS

(2) "Любое прерывание опасно для целостности, тем более если в момент прерывания идет запись в базу (например проведение документом, или обмены)." ахахах

(0) В одной умной книжке по SQL описывалась история: СУБД в серьезной организации, по ошибке запустили неправильный запрос на изменение данных. Поняли только после запуска. Рубанули электричество, чтобы транзакция не завершилась. После перезапуска SQL эту транзакцию сам откатил, всё ОК.
А вы тут с каким-то соединением.

Все,что делается в базе на сервере,не пострадает,так как транзакция,и код корректно завершится
Не забываем,что rphost никуда не завершается,а завершает алгоритм в одном из потоков.
Конечно,какие-то данные могут потеряться,так как не проведенный и не записанный документ превратится в пустоту.
Однако,если какая-то обработка выполняет действия не в одной транзакции,например обмен,где транзакция на определенное число объектов,то можно получить состояние на середине.

Даже при падении сервера 1с транзакции к базе данных успешно откатываются.

(2) Битая база в dt это намного более редкий случай чем битый sql бэкап ))

(8) Не факт что у него msSQL а не по постгри или файловая.
(9) даже если база файловая?

Какой RAS в файловой базе ?
А чем postgrrdql хуже mssql в момент завершения соединения и отката транзакции ?

Смею также заметить,что если серверный код выполняет http-запрос и ожидает соединения,то завершение сеанса произойдет по окончании вызова.
Так что это достаточно корректная операция,которая даже все дескрипторы открытых файлов закрывает.

(13) Моё дело сказать, а вы тут дальше разбирайтесь.

(15) Аргументировано сказать, а то подумают что дурак.

Всем спасибо, суть понятна.
Чтобы сеансы 1С отключать приемлемый вариант, в любом случае.
А главное "типовой".