метод AfterUpdate

[AlexeyVS]

Возможно ли выполнить логику ПОСЛЕ того как зафиксируется транзакция метода Update?

[Logger]

А зачем ?

[DSPIC]

Цитата:

Сообщение от AlexeyVS

Возможно ли выполнить логику ПОСЛЕ того как зафиксируется транзакция метода Update?

Возможно, см. Методы-события ttsNotify* на классе application/infolog

[S.Kuskov]

А автор вопроса случайно не это имел в виду?

public void update()
{
    ttsbegin;
    super();
    // TODO: AfterUpdate
    ttscommit;
}

[shlyopin]

может как-нить так:

public void update()
{
    ttsbegin;
    super();
    ttscommit;

   // TODO: AfterUpdate
}

[pitersky]

Мне кажется, что ставить ttsbegin/ttscommit внутри update - не очень хорошая идея.
Как правило, исполнять в одной транзакции надо не только внутреннюю логику update, но и внешние действия. А если там транзакция уже открыта, то внутри update она не нужна.
Словом, автору бы лучше найти ttscommit, подтверждающий выполнение update, а уже после него делать действия. Хотя у меня есть сомнения, что ему на самом деле надо что-то делать именно после ttscommit, а не после update.

[oip]

Цитата:

Сообщение от pitersky

Мне кажется, что ставить ttsbegin/ttscommit внутри update - не очень хорошая идея.

При необходимости ставить ttsbegin/ttscommit внутри update это как раз хорошая идея. Никакой метод (update или любой другой) не должен думать о необходимости открытия транзакции при его вызове. Если логика самого метода предполагает, что некоторый код в нем должен выполняться в рамках транзакции, то ttsbegin/ttscommit там должен быть. Для примера см. InventTable.update(), InventTrans.update() и прочие таблицы. Правда к вопросу топикстартера это не относится.

[AlexeyVS]

Приветствую! Спасибо за ответы, коллеги.

Объясню зачем все это необходимо. Данные по некоторым сущностям аксы должны быть интегрированы с другими системами. Интеграция происходит в реальном времени через веб-сервис. Даже если выполнять процедуру интеграции после инструкции ttscommit; в перекрытом методе update() и в результате вызова этой процедуры произойдет ошибка (например, сервис недоступен), то все транзакции update() будут отменены. Мне же надо произвести интеграционную процедуру именно после окончательной фиксации метода update().

[raz]

Сделайте таблицу с двумя полями RefTableId и RefRecId и пипшите в нее после update ссылку на обновленную запись. А в интеграции бегайте по этой таблице, находите нужную запись, передавайте данные и удаляйте записи с переданными сылками.

[S.Kuskov]

Цитата:

Сообщение от AlexeyVS

Даже если выполнять процедуру интеграции после инструкции ttscommit; в перекрытом методе update() и в результате вызова этой процедуры произойдет ошибка (например, сервис недоступен), то все транзакции update() будут отменены.

Ну этого можно избежать если ловить прерывания от процедуры интеграции и не позволять им откатывать транзакцию.

Здесь я вижу проблему в другом. Если проводить интеграцию внутри транзакции то появляется вероятность того что операция чисто теоретически может начать откатываться уже после того как отработает операция интеграции.

Поэтому, сами данные конечно могут передаваться во внешнюю систему и во время работы транзакции (т.е из метода update), но окончательное подтверждение того что эти данные вылидны должно происходить только после завершения транзакции (т.е. из метода Application.ttsNotifyCommit())

А вообще, имхо, интеграция на уровне транзакций - это задача уровня СУБД, а не AOS.

[AlexeyVS]

raz, S.Kuskov, именно так и задумывается!

С учетом того, что интеграция должна работать в реальном времени и позволять "догружать" записи при ошибках, будет реализована следующая схема.

В перекрытых методах CUD будет производится запись в некую таблицу (типа очереди интеграции). Куда будут записаны TableId-RecId. Это позволит нам ставить в очередь интеграции записи, транзакции которых были зафиксированы и данные валидны. Плюс в специальный List класса Application будут записаны ссылки на записи, которые надо интегрировать после ttscommit;

Затем в методе Application.ttsNotifyCommit будет производится сама процедура интеграции по совету DSPIC.

[ivas]

В методе update создаете тред, а уже в этом треде запускаете то, что должно отработать после метода update. Управление в новый тред перейдет после того как отработает вся текущая логика.

ttsNotifyCommit конечно хорошо, однако в общем случае в этот метод вы можете и не попасть например если вызов update и транзакции живут в другом соединении например: \Classes\NumberSeq\reserveNumInternal

[egorych]

Цитата:

Сообщение от oip

При необходимости ставить ttsbegin/ttscommit внутри update это как раз хорошая идея.

То, что разработчики напихали во все возможные места ttsbegin не является правильным для использования! Это имело бы смысл, если бы СУБД поддерживали параллельные транзакции в 1 сессии! Но это не так!
У МССКЛ присутствую т.н. "именованные" транзакции, но логика их работы абсолютно не такая, как кажется - не получится откатить 1 транзакцию и оставить активными другие!
В Оракле есть т.н. автономные транзакции, которые работают независимо, но это опять же не наш случай!
Так что мая ИМХА - если update должен работать внутри транзакции, то об этом должен позаботиться ВЫЗЫВАЮЩИЙ, а не надеяться на то, что где-то, кто-то стартанёт её !

[raz]

Цитата:

Сообщение от AlexeyVS

Затем в методе Application.ttsNotifyCommit будет производится сама процедура интеграции по совету DSPIC.

А нельзя вынести интеграцию за скобки? Т.е. пакетный сервер анализирует таблицу ссылок и передает актуальные данные. Поскольку он работает в своих транзакциях, то (при определенных настройках) будет видеть ссылки только с закоммиченными данными.

[AlexeyVS]

raz, тоже вариант. Как запасной, если не удастся реализовать через ttsNotifyCommit()