Спасибо, Евгений, получил детальный ответ после привлечения разработчиков.
Напишу суть тут, может кому пригодится:
[QUOTE]Если изменение элемента инфоблока выполняется через административную часть сайта, то описанная работа события OnAfterIblockElementUpdate такой и должна быть при условии, что это InnoDB.
В админке (хоть страница товара, хоть быстрое редактирование из списка) имеем:
[CODE]$DB->StartTransaction();
Update
if (ok)
$DB->Commit();
else
$DB->Rollback(); [/CODE]
соответственно, пока не выполнится Commit или Rollback - запись залочена, доступа к ней нет на изменение (кроме как в текущем контексте)
[/QUOTE]
Соответственно, невозможность из события обновления сделать запрос к странице товара (или другого элемента детально) - системное ограничение.
Единственный способ - отмечать где-то себе изменённые элементы и потом их проверять обработчиком на кроне или на агентах (тоже на кроне).
Я пока смотрю в сторону OnAfterEpilog, полагая, что к этому моменту транзакции уж точно должны завершиться.
Напишу суть тут, может кому пригодится:
[QUOTE]Если изменение элемента инфоблока выполняется через административную часть сайта, то описанная работа события OnAfterIblockElementUpdate такой и должна быть при условии, что это InnoDB.
В админке (хоть страница товара, хоть быстрое редактирование из списка) имеем:
[CODE]$DB->StartTransaction();
Update
if (ok)
$DB->Commit();
else
$DB->Rollback(); [/CODE]
соответственно, пока не выполнится Commit или Rollback - запись залочена, доступа к ней нет на изменение (кроме как в текущем контексте)
[/QUOTE]
Соответственно, невозможность из события обновления сделать запрос к странице товара (или другого элемента детально) - системное ограничение.
Единственный способ - отмечать где-то себе изменённые элементы и потом их проверять обработчиком на кроне или на агентах (тоже на кроне).
Я пока смотрю в сторону OnAfterEpilog, полагая, что к этому моменту транзакции уж точно должны завершиться.