Как можно блокировать действие или шаг действия?

[Anderyt]

хм... чем то чувствую, что можно без таблиц (как говорилось в "Ширли-Мырли" - "что то не нравятся они мне.. нет, я конечно не расист... ну так... чувствую какой то дискомфорт"... )
если в действии, которое берет значение счетчика, перед этим самым считыванием, установить для этого же объекта другой атрибут (типа "счетчик занят"), сделать update, потом считать, увеличить, записать и убрать флаг занятости, и тут же снова сделать update?
и перед всем этим сначала проверять, занят ли счетчик.. если не занят - начинаем его занимать и обрабатывать, если занят - снова проверяем, занят или нет...
если между двумя update не будет никакой реакции юзера, то вроде 2-е действие не будет слишком долго ожидать..

[Александр]

нет нет и нет
зачем?
я настаиваю на базовых функциях типа при редактировании действия добавить флаг в настройки действия - действие работает в многозадачном режиме или в однозадачном это будет проще, но правда несколько дольше

[Disillusioned]

Возникла мысль...
Что если заранее централизовано создать некоторое количество объектов-"пустышек" у которых из всех атрибутов один только номер и есть. Тогда пользователю надо не создавать новый объект-"документ", а изменить существующую "пустышку".
Для того чтобы один объект не взяли на изменение два пользователя:
- в первом шаге записать в атрибут код пользователя и следом Update(). "Бронируем" объект.
- создать бизнес-правило блокирующее изменение атрибута с кодом пользователя если такой атрибут существует.
- на втором шаге проверить, совпадает ли код пользователя? Если да, редактировать объект, если нет сообщить о том, что объект занят.
Создание новых "пустышек" можно повесить, к примеру, на сервер автопереходов (просто первое что пришло в голову).

P/S Можно разделить объекты "Номер документа" и "Документ". "Номера" создаем заранее, потом, по потребности, подключаем к ним "Документы". При таком подходе будут даже шаблоны прав работать.

P/P/S Проблему пробелов в нумерации этот подход также поможет решить... Видим, что номер свободный и используем несмотря на то что он не последний...

P/P/P/S Чтобы пользователь не заблудился в свободных номерах "Пустышки" можно хранить в недоступной пользователю папке и при запуске действия искать в ней через SQL наименьший незанятый номер...

P/P/P/P/S Наверное, можно обойтись и без "пустышек", также "бронируя" объект хранящий очередной номер документа. В действии, если счетчик не занят пишем в него код пользователя, потом Update(), потом проверка кода пользователя. После того как счетчик на единичку увеличили, атрибут с кодом пользователя удаляем и снова Update(). Если счетчик занят, в цикле ожидаем, чтобы он освободился... Бизнес-правило должно работать только на изменение атрибута, удаление должно происходить без ограничений.

[Anderyt]

P/P/P/P/S Наверное, можно обойтись и без "пустышек", также "бронируя" объект хранящий очередной номер документа. В действии, если счетчик не занят пишем в него код пользователя, потом Update(), потом проверка кода пользователя. После того как счетчик на единичку увеличили, атрибут с кодом пользователя удаляем и снова Update(). Если счетчик занят, в цикле ожидаем, чтобы он освободился... Бизнес-правило должно работать только на изменение атрибута, удаление должно происходить без ограничений.

хм.... где то я это уже видел... вот только не могу вспомнить, где именно...
Александр, вы хотите чтобы вообще все действие блокировалось????
ого..
а если оно большое? а если человека отвлекли, он начал говорить по телефону, а действие не закрыл?
все остальные будут его ждать??

[Александр]

я тут покурил и понял...
клиентские действия - лезут без очереди
серверные - в очередь
соответственно никаких двойных номеров - только вот проблема - мы не используем сервер автопереходов

[Александр]

>Anderyt
нет зачем ждать... действие должно быть полностью автоматическое и выходить если повисло по тайм-ауту - как wathdog в однокристаллках - завис - на перезагрузку...

в общем наверно только на сервере автопереходов проблема решится благоприятно, а вот как на клиентских местах без автопереходов???? нужно что-то совсем простое

может все тот же флаг в очередь или без очереди ... по моему должно работать (я все на перспективу смотрю, с дополнительными атрибутами что-то не очень хочется связываться - в конце концов мы же не программируем систему - а только настраиваем ее)

[Disillusioned]

хм.... где то я это уже видел... вот только не могу вспомнить, где именно...

Идею использования блокиратора я себе и не приписываю...
Просто факт занятости счетчика ровным счетом ничего не значит, если не известно, кто именно его занял, и нет механизма предотвращения повторной блокировки, т.к. запрос на установку блокиратора может поступить от двух пользователей "почти одновременно" и мы получим

вероятность одинаковых номеров стала намного меньше (но они каикм то образом все таки встречаются, но ОЧЕНЬ-ОЧЕНЬ редко).

[Anderyt]

ой... ой-ой-ой... какой такой watch-dog ???

нужно что-то совсем простое

пока мне самым простым решением видится блокиратор в самом действии с использованием дополнительного атрибута (Disillusioned придумал наконец название для того, что мы тут обсуждаем )

Идею использования блокиратора я себе и не приписываю...

да я ж не в упрек я ж шучу...

Просто факт занятости счетчика ровным счетом ничего не значит, если не известно, кто именно его занял, и нет механизма предотвращения повторной блокировки, т.к. запрос на установку блокиратора может поступить от двух пользователей "почти одновременно" и мы получим

хм... а механизмом предотвращения повторной блокировки разве не будет тот самый цикл проверки наличия блокировки?... че то я запутался тогда

[Anderyt]

оофтопик, но я уже давно не видел на форуме одновременно ЧЕТЫРЕХ человек!

[Александр]

watch-dog сторожевой таймер на действие если-бы лоция была зашита в плисине вот можно было-бы развернуться то!!! соскучился уже я по ним по микросхемам родным

я видел 7 сегодня 5+2глюка эт я о форуме

[Disillusioned]

хм... а механизмом предотвращения повторной блокировки разве не будет тот самый цикл проверки наличия блокировки?

Пример:
Два пользователя "почти одновременно" (разница в доли секунды) запустили действие. Если первый еще не успел установить блокиратор и выполнить Update(), второй получит информацию о незаблокированном счетчике. В обоих действиях будет выполнен AttribSet для установки блокиратора и оба действия будут считать, что работают со счетчиком в монопольном режиме. Такие ситуации будут, вопрос только в вероятности их возникновения.

Собственно, код пользователя, получается, и необязателен. Достаточно бизнес-правила. Тогда первый пользователь установит блокиратор, а у второго сработает бизнес-правило... Надо только сразу после блокировки update() сделать.

[Anderyt]

Два пользователя "почти одновременно" (разница в доли секунды) запустили действие. Если первый еще не успел установить блокиратор и выполнить Update(), второй получит информацию о незаблокированном счетчике. В обоих действиях будет выполнен AttribSet для установки блокиратора и оба действия будут считать, что работают со счетчиком в монопольном режиме. Такие ситуации будут, вопрос только в вероятности их возникновения.

вот блин...
ну да, похоже...

Собственно, код пользователя, получается, и необязателен. Достаточно бизнес-правила. Тогда первый пользователь установит блокиратор, а у второго сработает бизнес-правило... Надо только сразу после блокировки update() сделать.

блокиратор - это все равно какой то дополнительный атрибут?
а что будет, когда сработает бизнес-правило? будет ошибка в действии?
как ее перехватывать?..
а если вместо attribset для установки блокиратора использовать attribadd - эффект будет другой?
просто боюсь приближаться к бизнес-правилам..
кстати..

Что если заранее централизовано создать некоторое количество объектов-"пустышек" у которых из всех атрибутов один только номер и есть. Тогда пользователю надо не создавать новый объект-"документ", а изменить существующую "пустышку".

мне кажется, нет такой необходимости.. такие объекты уже скорее всего созданы - откуда то ведь действия берут текущие значение счетчика?

[Disillusioned]

блокиратор - это все равно какой то дополнительный атрибут?

Он самый.

а что будет, когда сработает бизнес-правило? будет ошибка в действии?

Так точно. Не очень красиво, но если учесть что пересечение пользователей по времени очень маловероятно, на это можно не обращать внимание.

а если вместо attribset для установки блокиратора использовать attribadd - эффект будет другой?

Эффект будет тот же самый.

просто боюсь приближаться к бизнес-правилам..

Настоятельно рекомендую приблизится, полезная штука!

[Anderyt]

Цитата:
Эффект будет тот же самый.

фуф... ну я выходит хоть что то понял
ок, спасибо!
думаю, если у нас снова поднимется вопрос с дубликатами - буду настраивать так, как договорились в этой ветке

[Старик Крупский]

да кто его знает..
сейчас вроде шаг с тремя функциями не моежт считаться одной транзакцией...

Если вызывать действие из действия, то вложенное действие и будет транзакцией. А судя по информации из Лоции - это будет уже в ближайшей сборке 4.30.