Inclusion in database transactions

[Ion]

Всем привет!

Есть проблемы в плане области видимости рекордов. Речь идет о создании записи и плагине Post-operation (execution mode == sync). Насколько я понимаю, то данные в CRM и логика работы плагинов должна быть построенна исходя из уровня изолированости read committed.
То есть если у меня плагин и он последний в плане Execution Order, и в нем происходит ексепшен, то транзакция не была/не должна быть закомиченна полностью и происходит rollback. И по сути этот рекорд не должен быть visible из вне - так по крайней мере говорит мне логика что dirty reads не должно быть.
Но по-факту, у нас другая ситуация - и рекорд можно считать использую xrm (без NoLock = true).

Мне от интересно сама природа плагина играет в этом процессе роль: вызов SOAP сервиса и эксепшен в нем могут спровоцировать такую странную реакцию платформы при условии что все происходит синхронно?

Просто я не понимаю где гарантии?

Цитата:

If a plug-in is executing in the database transaction and allows an exception to be passed back to the platform, the entire transaction will be rolled back. Stages 20 and 40 are guaranteed to be part of the database transaction

То есть да, идет откат и рекорд удаляетсья из базы, но он же был визибл во время создания через публичный XRM API и пока последний плагин не завершил свой екзекюшен - разве может транзакция считаться закомиченной.



MS утверджает, что

Цитата:

Any registered plug-in that executes during the database transaction and that passes an exception back to the platform cancels the core operation. This results in a rollback of the core operation. In addition, any pre-event or post event registered plug-ins that have not yet executed and any workflow that is triggered by the same event that the plug-in was registered for will not execute.

Или я чего-то понимаю или это баг.

[Артем Enot Грунин]

Увы, я не смог проследить вашу мысль. Вся воронка обработки, действительно, выполняется в транзакции. Увы, не могу с уверенностью утверждать, создаются ли дочерние транзакции под каждый плагин, или дочернее событие, но с уверенностью могу сказать, что каждый последующий плагин видит изменения, которые были внесены предыдущими. И это, имхо, правильно. Если вам нужно видеть исходные, не измененные данные, вы можете использовать механизм Image

[ZooY]

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

[Артем Enot Грунин]

Коллега, вы в корне не правы. Начиная с 2011 все синхронные плагины, и пре и пост, выполняются внутри одной транзакции. Ошибка на пост событии так же ведет к откату транзакции, несмотря на то, что данные уже были записаны в базу. На самом деле, они, к этому моменту были записаны только в лог транзакции, но не суть.

[ZooY]

Да, чет фигню сморозил

А вот ваше замечание о том, что данные записываются в лог транзакции - это не ответ на вопрос почему они доступны для считывания?

[Ion]

Цитата:

Сообщение от Артем Enot Грунин

Увы, я не смог проследить вашу мысль. Вся воронка обработки, действительно, выполняется в транзакции. Увы, не могу с уверенностью утверждать, создаются ли дочерние транзакции под каждый плагин, или дочернее событие, но с уверенностью могу сказать, что каждый последующий плагин видит изменения, которые были внесены предыдущими. И это, имхо, правильно. Если вам нужно видеть исходные, не измененные данные, вы можете использовать механизм Image

Механизм у нас следующий: есть СРМ система и есть стороння система которая по скедулу забирает данные скажем по сущности "Заказы", исполязуя XRM API. На сущность заказы подвешен плагин и он исполняеться всегда последним. Допустим, в нем происходит эксепшен и все данные откатываються, удаляються из базы СРМ.
Но в это же самое время другая система делает кол через XRM API, и говорит: - А дай-ка мне последние созданные заказы. И мне неясно почему этот заказ стал видим если в последнем плагине произошел эксепшен и он откатился?
У нас же read commited, почему присутствует грязное чтение?
Мы можем его стабильно воспроизвести. Написали две тулы: первая - пишет данные в СРМ с прекондишеном, что в плагине будет эксепшен; вторая - как консолька мониторит новосозданные рекорды и забирает их к себе в систему.
От и весь сценарий, в систему попадают ИД заказов которых нет.
В той системе формируеться урл на рекорд из СРМ. Узер открывает запись, а ее в системе нет.

[Артем Enot Грунин]

Они доступны только внутри той же транзакции, все логично. Если вы остановите плагин отладчиком и посмотрите на данные через интерфейс, вы увидите не измененные данные.

[Артем Enot Грунин]

Ни разу не встречал подобное. Технически, грязное чтение можно разрешить, но по дефолту оно выключено: https://community.dynamics.com/crm/b...nd-dirty-reads

[Ion]

Цитата:

Сообщение от Артем Enot Грунин

Ни разу не встречал подобное. Технически, грязное чтение можно разрешить, но по дефолту оно выключено: https://community.dynamics.com/crm/b...nd-dirty-reads

В этом и есть проблема, что NoLock = false, как я писал в первом сообщении.
Приходиться только развести руками, потому что идей как это решить нет.

[a33ik]

Проблема решается примитивно просто (как по мне). Делаете дополнительную таблицу, в поспроцессинге пишете туда идентификатор новой записи. В своём сервисе перед тем, как спрошать эндпоинт - получаете идентификатор из таблицы. Никаких проблем вроде.

Понимаю, что доп прослойка, но зато вы получаете только актуальные данные. Я так в своё время писал интеграцию с 1С.

[Ion]

Цитата:

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

Проблема решается примитивно просто (как по мне). Делаете дополнительную таблицу, в поспроцессинге пишете туда идентификатор новой записи. В своём сервисе перед тем, как спрошать эндпоинт - получаете идентификатор из таблицы. Никаких проблем вроде.

Понимаю, что доп прослойка, но зато вы получаете только актуальные данные. Я так в своё время писал интеграцию с 1С.

Спасибо за идею! Когда говорил про развести руками, имел ввиду именно этот бихевиор. Хотелось бы решить саму первопричину. Но насколько я понимаю репортить баг или писать в техподдержку МС гиблое дело.

[a33ik]

Открытие сапорт тикетов в МС в особенности если у вас онпрем - сейчас гиблое дело. Я уже сталкивался. Даже премиум сапорт зачастую не решает тикеты.

Так что, боюсь, придётся вам решать проблему через доппрослойки...

[Ion]

Цитата:

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

Открытие сапорт тикетов в МС в особенности если у вас онпрем - сейчас гиблое дело. Я уже сталкивался. Даже премиум сапорт зачастую не решает тикеты.

Так что, боюсь, придётся вам решать проблему через доппрослойки...

Єх, спасибо за ворк єраунд. Думаю так и сделаю если вариантов негусто