|
ISGRесли Вы не видите в этом серьезных проблем например для УПП, Вы либо очень хороший специалист и я готов взять Вас на работу, либо просто не понимаете объем и сложность работ Я не специалист в 1с (пока; дальше, надеюсь, им стану, т.к. сейчас усиленно изучаю эту платформу). Однако в моей практике был период (более 10 лет) программирования на одном из dbf-языков в связке с ADS-сервером. И там ни одной операции нельзя было сделать без предварительной установки блокировки (уровня записи, есс-сно). И не дай бог забыть эту блокировку снять после того, как запись будет завершена.
Общее число строк в той программе было ~150'000. Сами понимаете, что количество мест, где надо было "ручками" ставить и снимать блокировки, исчислялось, наверное, не одной сотней. Тем не менее, я остался жив и невредим :-). Код, записывавший в БД инфу, практически всегда был "содран" с шаблона, примерно такого:
1) проверить служебный массив на наличие в нем имени функции, являющейся инициатором транзакции; если такого имени там нет, то добавить туда имя текущей функции;
2) получить имена таблиц, в которых требуется провести запись;
3) для каждой такой таблицы получить список строк, в которых будут обновлены данные;
4) запросить блокировки строк последовательно для всех таблиц; для добавляемых строк - запросить блокировки на добавление записей;
5.1) при отказе в п. 4 -- снятие всех предыдущих блокировок и выход с кодом возврата меньше нуля ("авария"), т.е. переход к п. 10;
5.2) при получении ВСЕХ строковых блокировок -- повторная проверка допустимости выполнения
текущей операции (блокировки могли устанавливаться не мгновенно!);
5.2.1) если в предыдущем пункте какая-либо проверка НЕ выполнена, снятие всех предыдущих блокировок и выход с кодом возврата меньше нуля ("авария"), т.е. переход к п. 10;
6.1) если текущая функция является инициатором транзакции [см. пункт 1: проверяем служебный массив!], то объявить начало транзакции (BEGIN TRANSACTION)
6.2) иначе проверить, не выполняется ли текущий код внутри активной транзакции (то есть, была ли объявлена транзакция).
6.2.1) Если да, то перейти к п. 7;
6.2.2) Иначе - выход БЕЗ снятия блокировок (переход на п. 11, код возврата 0)
7.1) запись в таблицы (ТОЛЬКО ТУТ в разных местах программы были разные операторы);
7.2) если текущая функция является инициатором транзакции, то перейти к п. 8); иначе -- перейти к п. 11 (выход БЕЗ снятия блокировок, код возврата равен 0);
8) проверка бизнес-правил перед завершением транзакции;
9) если в предыдущем пункте какое-то правило не выполнено -- ROLLBACK и установка кода возврата меньше нуля ("авария"); иначе -- COMMIT;
10) снять блокировки со всех таблиц. Очистить служебный массив с именами таблиц, номерами строк и именем функции-"инициатора" транзакции
11) выход с кодом возврата (0 = Ok, <0 = Error)
Так вот: самым трудным было не "сочинение" этой схемы, а создание механизма, благодаря которому одни и те же функции, проводящие запись, могли бы "понимать", имеют ли они право ОБЪЯВИТЬ ТРАНЗАКЦИЮ (п. 5) или нет (и, соот-но, могут ли они проводить сейчас запись и проверять бизнес-правила для COMMIT/ROLLBACK'a). Потому что в том ADS-сервере не было понятия "вложенной транзакции" (да и вообще это какое-то "странное" понятие, имхо). Программный модуль должен каким-то образом понимать, выполняется ли он ВНУТРИ кода, который является "инициатором" транзакции, или эту транзакцию надо делать ему самому. Этот механизм был реализован в виде служебного массива, в котором содержится имя функции, являющейся "инициатором" транзакции -- см. п 1 в вышеприведенном описании.
Подчеркну еще раз: мои воспоминания о той "эпопее" сводятся к тому, что самым сложным является не кодирование "ручками" (берётся шаблон-болванка и методом copy/paste вставляется в новое место). А именно разработка механизма, позволяющего функциям (модулям) "понимать", имеют ли они право объявить транзакцию и завершить её, или НЕ имеют (т.к. работают в "подчинённом" режиме).
ЗЫ. Насчет того, что не понимаю объем и сложность, Вы не правы: еще как понимаю. Потому и завёл этот топик.
Но у меня появились вопросы по блокировкам, к-рые надо ставить в управляемом режиме:
1) есть ли возможность циклического повтора попытки установить к-л блокировку на строку, если в данный момент времени эта строка занята ? То бишь, существует ли в 1с некий механизм, позволяющий в цикле запрашивать блокировку и ждать некоторое время в случае неудачи (с возможностью прерывания юзером этой попытки и возвратом в исходный режим) ?
2) после получения блокировки приложение часто должно проверить заново состояние данных в той строке, которую оно так страстно "домогалось" (потому что за время ожидания блокировки данные в этой строке могли стать уже другими, в т.ч. такими, при которых выполнение операции становится недопустимым -- например, было списано последнее изделие и текущий остаток стал равен 0). Так вот: есть ли в 1с некая "штатная" возможность повторной проверки на допустимость выполнения операции, уже после того, как все блокировки получены ? Или это тоже надо делать "руками" ?
3) запоминает ли 1с в какой-нибудь структуре (массиве ?) те строки, которые оказались заблокированными, и можно ли к ним обращаться напрямую, БЕЗ SQL-запросов, т.е. примерно как через "goto" ?
И еще: есть ли в 1с понятие static-переменной (и массива), в том смысле как в Си: чтобы после окончания работы функции эта переменная "жила" и её можно было бы задействовать при новом вызове этой функции ? Без static-переменных реализация того алгоритма, который я привёл, будет просто невозможна (т.к. все функции вызываются фактически ДВАЖДЫ: сначала для установки блокировок, а затем для записи).
|
