|
FZTЗдравствуйте.
Вопрос узкой специфики.
Выполняется некая "атомарная" операция в 1С предприятии, суть не в самой операции. Под атомарной операцией прошу понимать некий набор действий с данными (в нашем случае изменяющий их), имеющих своей целью логическую завершенность. Допустим проведение документа.
Разберем такой случай работы с данными. Пусть в момент времени исполнения такой атомарной операции, данные будут меняться в: реквизитах самого документа, его табличных частях, некоторых регистрах (дополнительные свойства конкретно этого документа). Итого три "места", где данные изменяться.
В самой 1С сработает одна функция, которая изменит данные по порядку в трёх местах.
Вопрос первый
На стороне SQL сервера, на вход будут поданы:
1. Три запроса подряд? т.е. каждый - отдельная транзакция
2. Три запроса в рамках одной транзакции?
3. Изменения будут агрегированы движком (вот уж не знаю как он внутри устроен) в один SQL запрос, а рамках одной транзакции?
Под транзакцией понимать только то, что принято для SQL серверов.
Лично я склоняюсь к варианту один. Отсюда второй вопрос.
Разумеется в момент выполнения атомарной операции может произойти сбой. По сути функция до краха попыталась записать данные только в реквизиты документа 1С и табличную часть, а разработчик функции не предусмотрел откат данных в первоначальное состояние, или форс-мажор какой с клиентом случился.
Что произойдет на стороне SQL сервера:
1. Применяться изменения только для реквизитов документа и табличных частей, и данные в регистре не будут согласовываться с документом?
2. Неким непонятным мне образом (можете объяснить? допустим обрыв связи, или питания у клиента), все изменения касающиеся конкретно этого документа будут отменены?
Несколько десятков книг с документацией по 1С присутствуют на столе, искал ответ в каждой. В интернетах гуглил безрезультатно.
P.S. Пожалуйста не отвечайте в эту тему если у вас отсутствует личный опыт в поднятых здесь вопросах, или вы не можете сослаться на официальный или авторитетный (хотя-бы для Вас лично) источник информации. Тем-более если Вы "просто программист 1С", не отягощенный регалиями знаний T-SQL, ООП, многопоточности.
Постскриптум такого содержания - это хамство, я тагду. оскорбление, квантор,
презумпция тупости и т.д.
[Лично я склоняюсь к варианту один.] - прямое следствие из содержания посткриптума,
считать других людей идиотами, а разработчиков платформы 1С - идиотами в квадрате.
Неленивый человек запустит 1С в режиме отладки, откроет профайлер MS SQL и будет не
склоняться, а - знать. Это куда проще, чем гуглить и штудировать дестяки книг.
"Атомарность" - это какая-то отсебятина применительно к бизнес-логике и поведению
СУБД. Транзакция.
Несколько простых упражнений, особенно с обработчиками событий, предоставят полный
и исчерпывающий ответ.
автор3. Изменения будут агрегированы движком (вот уж не знаю как он внутри устроен) в один SQL запрос, а рамках одной транзакции?
я, например, не в состоянии представить себе такой один SQL-запрос, изменяющий
совершенно разнородные данные в двух десятках таблиц.
Одну транзакцию - могу. Один запос - нет.
["А нафига?" - Рассматриваю лог транзакций MsSQL 2005, на предмет резервирования в реальном времени. Т.е. будет ли лог транзакций MsSQL, накаченный на ночной бэкап, соответствовать действительности. Вплоть до атомарности операций из 1С, к моменту краха системы.]
как вы считаете, может серьезная платформа выйти на рынок и иметь миллионы
инсталляций в серьезных компаниях, а тем паче в малых конторках, если
она не выполняет первейшее требование - транзакционную целостность?
Я знаю ООП, многопоточность, IMAP, TCP/IP, AutoCAD, SQL, VB, JS, 1C, Delpho, COM, SMTP,
OLE, patterns, UML, MS Project, case sensitive, EJB, Sharepoint, POP3, asm, hiew!
|
