()
Как Вы себе представляете освобождение блокировки внутри транзакции? И как должна повести себя система в таком случае, если транзакция еще длится, а незакоммиченные данные уже свободны для изменения? А если будет в конце * транзакции?
Ну это интересная и тема, пожалуй требующая глубокого мыслительного процесса, по результатам которого можно целую статью написать. Но если на вскидку попробовать кратко то вот так:
Надо сразу определиться с тем, сколько у нас может быть разных ситуативных сценариев (в общем случае, а не только то, что может сейчас платформа 1С Предприятие 8 и СУБД). А, на вскидку, имеем 4 ситуации (2 на 2 вариантов)
Два варианта - это какие данные мы блокируем - неизменяемые, или изменяемые
Два варианта - это какие способы у нас есть изменения данных: только полная замена значения, или доступны более хитрые операции
Рассмотрю эти сценарии (в транзакции):
1. Обычные операции изменения. Блокировка изменяемых данных.
Навскидку в такой ситуации есть резон блокировать данные до момента их изменения. И нет смысла отпускать блокировку явно, до завершения транзакции. Но, возможны нюансы:
1а. Могут быть случаи явной предварительной блокировки изменяемых данных без их фактического изменения. При этом алгоритм может понять, что эти данные ему не нужны за долго до завершения транзакции – и принять решение о том, чтобы их отпустить – чтобы не мешать другим алгоритмам (оставим пока в стороне проблемы взаимных блокировок – это уже другой вопрос и с другой правильной стратегией решения, явно непротиворечащей данной ситуации), пока ещё выполняется текущая транзакция.
1б. Могут быть случаи, когда данные нужно заблокировать, изменить и тут же отпустить. Не завершая текущую транзакцию (но внося изменения в СУБД) – это уже задача формирования параллельной транзакции (немножко другая тема), но по факту такие задачи тоже могут возникать (у меня возникали). Кстати на 1С Предприятие 8 такую ситуация «через одно место» но реализовать можно – параллельные транзакции можно открывать фоновыми заданиями.
Кстати итоговая транзакция в конце может как успешно зафиксироваться, так и откатиться. И это всё тоже по-разному может отработать (в случае отката – можно на это «подписаться» и тоже выполнить какие-то действия «освобождения»)
1в. Могут быть ситуации, когда данные меняются временно – нужны только для текущего алгоритма выполнения, но нужно отразить их в СУБД. А потом отменить и блокировку и изменения, не откатывая всю транзакцию – но это уже совсем специфическая ситуация. Чаще всего решаемая временными таблицами. Но, кстати, удерживание временных таблиц – это тоже хороший повод для реализации стратегии управления явным освобождением ресурсов.
2. Обычные операции изменения. Блокировка неизменяемых данных.
Вполне себе рядовая ситуация – когда нужно получить целостный кластер данных из СУБД, в промежутках получения которого уже полученные данные не изменятся. А после получения всех данных – блокировку можно смело снять, продолжая текущую транзакцию. Так как по сути изменение исходных данных уже не должно повлиять на алгоритм – т.е. работа с версией слепка данных. В конце транзакции можно, при необходимости, привести контрольное получение всех данных – и если что-то изменилось принято, то или иное решение. Например, оставить транзакцию зафиксированной, но пометить – что какая-то бизнес операция может быть неактуальной – и её нужно будет актуализировать позже.
3. Расширенные операции изменения. Или отложенные во времени операции изменения. Блокировка изменяемых данных.
Если в нашем распоряжении по изменению данных есть что-то больше чем тупое устаревшее присвоение с поной заменой нового значения. То можно делать более хитрые и более сводные от ожидания на блокировках операции изменения данных. Например, будь у нас относительные операции изменения как «Плюс» («Минус») – то можно вносить изменения в ресурс относительно – тогда в ряде практических сценариев можно не держать блокировку ресурсов долго – и отпустить их сразу после завершения относительной операции. Само собой операции чтения таких ресурсов должны уметь поддерживать нефиксированные значения (двойные: одно устаревшее зафиксированное, другое оперативное, но готовое измениться в любую сторону в любой момент, в т.ч. при откате транзакции).
Аналогичным может быть сценарий, добавления новых записей в таблицу (так называемых вероятно фантомных, или записей не повторяющегося чтения) – мы можем заблокироваться на время защитив себя от таких записей, а потом снять блокировку, когда нам это уже будет не важно, но ещё до завершения транзакции. Ведь если есть алгоритм, который хочет внести такие записи – то он всё-равно их может внести, просто сейчас дождавшись завершения блокировки-транзакции – но на первый алгоритм это никак уже не повлияет. А задержка на блокировке может быть существенной. Так же как если бы это были фантомы – которые потом «задним числом» исчезнут. Это всё проблемы, которые нужно решать скорее не блокировками, а другими сценариями контроля.
Так же в этот сценарий можно включить изменения данных, которым не важно кто-то их изменил последним. Которые в процессе транзакции могут по нескольку раз считываться и изменятся.
А ещё – операции изменения могут быть отложенными во времени – например, нужно частично провести сейчас (оперативно), а полностью позже (отразить в остальных разделах учета). Тогда можно оперативны ресурсы заблокировать сразу, внести оперативные изменения, отпустить оперативные ресурсы. И только потом приступить к прочим длительным алгоритмам формирования остальных движений.
4. Расширенные операции блокировки. Блокировка неизменяемых данных.
Могут быть сценарии, когда нужно заблокировать неизменяемые данные, так, чтобы их, на время их обработки их никто не мог другой заблокировать (но их можно было читать), при этом ещё и можно было бы получать все незаблокированные (или наоборот – текущие заблокированные). И в процессе их дальнейшей обработки поочередно каждый или выборочно отпускать, снимая блокировку – давая возможность их обрабатывать параллельным транзакциям. Это могут быть, например, какие-то триггерные-дескрипторы, управляющие параллельными процессами обработки связанных с ними данных.
Это я кратко изложил идеи. Конечно тут много над чем стоит подумать и проработать. Но это уже статью надо готовить. Суть в том – чтобы снижать время блокировки ресурсов. В идеале – стараться их вообще не блокировать и вести учет в рамках недетерминированных значений ресурсов.
В чем польза явной типизации? Ну вот хотя бы пару примеров. На грабли только натыкаться. Да и как это применимо в рамках конфигураций 1С? Пару мегабайт памяти экономить, чтобы возросла стоимость разработки и сопровождения?
1. Это упрощает процесс кодинга – когда сразу известны ожидаемые типы – подсказки IDE (малую толику таких подсказок уже можно увидеть в EDT, да и стандартный конфигуратор частично тоже умеет выводить типы – просто очень ограничено), автодокументация, более быстрое понимание алгоритмов и API, снижение числа ошибок, упрощение контроля входных данных, упрощение автоматизации тестирования. Более явное обозначение мест реального возникновения ошибки по всему дереву стека вызовов (т.е. откуда фактически пошли неверные входные данные). Логические ошибки тоже сокращаются – если внутри функции аргумент должен быть номенклатурой (и так он записывается в регистр, например), а в функцию передадут номенклатурную группу – то никакой ошибки не будет даже в рантайм – а запись в регистре будет неверной (пустое значение, если номенклатрные группы не поддерживаются, а если поддерживаются - то всё-равно это может быть не ожидаемое значение и оно всплывёт где-то позже – и попробуй потом найди «откуда ноги растут»). Ведь исходное значение может придти откуда угодно – да хоть из внешней системы. Будете тратить время на проверку каждого аргумента в коде? Или проще в пару слов задать ожидаемый тип как я указал выше, и всё проверки сделает платформа – причём постарается вынести их как можно ближе к реально получаемым исходным данным!
2. Упрощение кодогенерации, особенно при применении рефлексии – можно писать препроцессоры, которые на основе одного кода буду генерировать другой код.
3. Оптимизация алгоритмов – не столько за счёт сокращения объёмов памяти, а сколько из-за сокращения проверок в рантайм, а так же лишних левых соединений при обращении через точку к составным типам.
Стоимость разработки и сопровождения возрастает не значительно (да и в моём предложении для 1С Предприятие 8 я описал доп возможности, которыми можно не пользоваться, например, в тривиальных случаях). А вот анализ такого кода станет куда более простым – а значит, как раз сопровождение в дальнейшем будет проще.
1С в свое время и заняла рынок тем, что порог входа низкий, любая организация в максимально сжатые сроки максимально дешево перенесли бизнес-процессы в программу. Для любителей садо-мазо есть ABAP в SAP.
Тогда да – но времена изменились. Теперь из-за этого 1С теряет рабочую силу – современным программистам язык 1С кажется динозавром из прошлого. А бывалые 1С-программисты тоже чертыхаются из-за того, какой сложный и замороченный программный код выходит «из под пера 1С» в силу ограниченности языка и платформы, и как сложно его расширять, поддерживать и обновлять. И тут тоже начались уже потери кадров.
Да и вообще классические платформы учета теряют уже актуальность – простота создания учётных систем на них стала не так критична. Ибо на обучных языках программирования прошёл серьёзный прогресс и писать такого рода системы стало куда проще и комфортнее. Как и искать таких специалистов. А ещё в моде нынче опенсорс. И экономия на лицензия. Плюс ориентир потребления на сферу web и мобильных клиентов – где в тренде стали совсем другие подходы к фронтенду и клиент-серверному взаимодействию так же не пользу старых проприетарных учетных систем. Но западные системы уже начали меняется и подстраиваться под новые реалии.
Бакэнд разработка тоже давно угла вперёд – в моде облака, параллельные и распределённые вычисления, микросервисы и гибкая интеграция с разносторонним софтом через шины данных.
В тренде AI системы, голосовое управление, умная кодогенерация и машинное обучение.
В общем мир изменился – то что ранее было привлекательно, сейчас уже просто ржавый якорь.
Новым платформам и ЯП нужно быть в тренде, чтобы не остаться за боротом. А упрощение должно идти за счёт умных IDE с AI ассистентами, инструментами анализа и рефакторинга программного кода, повышения его прозрачности и лёгкости модификации, сопровождения и обновления. ЯП должен быть привычным актуальному мировому тренду. И иметь мощные привлекательные фишки, выделяющие его на фоне других систем. Большая часть кода должна формироваться автоматической и полуавтоматической кодогенерацией.
Именованные параметры, ну да, удобнее, но мне ближе питоновский синтаксис словаря, коротко и ясно:
Структура = {"Фамилия": "Иванов", "Имя": "Иван"}
Я, кстати, не об именованной передачи аргументов говорил. И не об определении структура.
Но если Вы об этом заговорили. То питоновский подход мог бы быть близок к текущей идеологии конструирования объектов типа «Структура» в 1С8 (хотя подход из JS мне нравится больще).
Но у него могут быть проблемы с операциями рефакторинга и с подсветкой синтаксиса.
А я, всё-таки говорил о кортежах, у которых значения могут и не быть именованными (а могут и быть – тогда это просто более легковесные структуры – передаваемые по значению, а не посылке)
Например так (на расширенном синтаксисе 1С8)
Перем к,к2, а, б, в;
к = (10, ”стр”, Истина);
(а, б, в ) = к;
к = (а:=10, б:=”стр”, в:=Истина);
к2 = (a:=0,б:=0,г:=0,б=0);
к2 := к; // к2 заполнит значения (a:=10,б:=”стр”,г:=0,б=Истина)
Простите, за кривоватый пример – лень сейчас придумывать красивый
