|
Вопрос по обработку отката транзации
|
|||
---|---|---|---|
#18+
В Cache'e есть какая либо возможность отловить вызовы trollback что бы выполнить свой код по факту отката транзакции? Или скажем понять что между двумя временными точками был trollback? Не по журналу, так как это наверное точно можно но наверняка жутко медленно, а по каким либо "флагам", "счетчикам" процессов области, номерам завершенных транзакций? Callback метод %Rollback для объектов это не то, он я так понимаю, срабатывает только если в %Save что то пошло не так, а мне хотелось бы обнаружить факт произведения произвольного tro ... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2019, 08:45 |
|
Вопрос по обработку отката транзации
|
|||
---|---|---|---|
#18+
Ptn , тестовый пример сделай для иллюстрации... ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2019, 08:56 |
|
Вопрос по обработку отката транзации
|
|||
---|---|---|---|
#18+
Факт наличия открытой транзакции на текущий момент так же подойдет ... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2019, 09:01 |
|
Вопрос по обработку отката транзации
|
|||
---|---|---|---|
#18+
krvsaестовый пример сделай для иллюстрации... ;) Тут не пример, тут постановка задачи скорее всего. Вот смотрите, есть ряд таблиц с данными, на основе которых некий метод вычисляет некий агрегат, что бы не вычислять каждый раз значение метод использует временный глобал для кеширования, и основная проблема убедится что кеш устарел. В триггерах и callback таблиц можно использовать выставление флага через $increment аля Код: c# 1.
инкримент не откатывается в tro и оставляет четкий след что было изменение начальных данных. Но я не учел что может быть долгая или вручную открытая транзакция которая откатывается после кэширования результата, то есть Код: plaintext 1. 2. 3. 4.
В такой последовательности я получаю невалидный кеш до ближашего изменения начальных данных, и никак не могу это обнаружить И что неприятно TROLLBACK вообще может быть в соседнем процессе относительно вызова подсчета агрегата, главно что бы он исходные данные задевал. По идее для обнаружения проблемы мне достаточно номера последней откаченной транзакции, анализируя который можно предположить невалидность кеша ... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2019, 09:14 |
|
Вопрос по обработку отката транзации
|
|||
---|---|---|---|
#18+
$TLEVEL - узнает кол-во открытых транзакций. Может быть на основе этого сделать логику. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2019, 10:06 |
|
Вопрос по обработку отката транзации
|
|||
---|---|---|---|
#18+
PtnТут не пример, тут постановка задачи скорее всего. Тестовый пример всяко лучше... Если ты его не можешь сделать - уже говорит о многом. Обычно о хотении чего-то заоблачного. Причем настолько, что его нельзя представить в виде схематичной, небольшой программки. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2019, 10:08 |
|
Вопрос по обработку отката транзации
|
|||
---|---|---|---|
#18+
vassil, $TL это уровень транзакции в текущем процессе, если соседний процесс изменил начальные данные а потом откатил, ты об этом не узнаешь. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2019, 10:52 |
|
Вопрос по обработку отката транзации
|
|||
---|---|---|---|
#18+
krvsa, Ты мой ответ читал вообще? Там пошагово описан пример. Давай не будем оценивать друг друга. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2019, 10:55 |
|
Вопрос по обработку отката транзации
|
|||
---|---|---|---|
#18+
Документация либо молчит либо намекает что такое узнать нельзя. Видимо придется смотреть в сторону LOCK удерживаемого до TCOMMIT или TROLLBACK ... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2019, 10:56 |
|
Вопрос по обработку отката транзации
|
|||
---|---|---|---|
#18+
PtnДавай не будем оценивать друг друга. Проблема твоя - тебе и решать... ... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2019, 14:02 |
|
Вопрос по обработку отката транзации
|
|||
---|---|---|---|
#18+
Ptn, Есть у меня подозрение, что счетчик откатов транзакций должен быть реализован. Вопрос только в том как получить к нему доступ. Возможно имеет смысл задать вопрос на Developer Community, и может быть даже кто нибудь ответит. Или стоит спросить через WRC. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2019, 17:40 |
|
Вопрос по обработку отката транзации
|
|||
---|---|---|---|
#18+
Ptn Код: c# 1.
инкримент не откатывается в tro и оставляет четкий след что было изменение начальных данных. В данном случае оно не откатится еще потому, что это CACHETEMP нежурналируемая база. Вы делаете один кэш на несколько процессов, а потом боретесь с тем, что данные меняются в параллельных процессах? И при этом не блокируете ресурсы? Но вы же как-то отслеживаете их изменение? Хотите отслеживать откат транзакций других процессов? Откат транзакций делается либо вручную, либо по ошибке. И в том и другом случае можно добавить код для пересчета кэша. А за длительные транзакции нужно вообще бить по рукам. В общем, мне кажется, вопрос больше к архитектуре приложения, а не возможностям Каше. Была мысль, что такая же проблема должна быть при работе с битовыми индексами, потом подумал, что битовые операции скорее всего журналируются особым образом, и откатывается только один бит, а не вся строка. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.04.2019, 20:55 |
|
Вопрос по обработку отката транзации
|
|||
---|---|---|---|
#18+
Вопрос решен. Дополнил инкримент блокировкой левого глобала ^BlaBla с последующей разблокировкой , которая остается висеть до конца завершения транзакции. Соответственно без относительно процессов. - если ^CacheTempUserBlaBla больше нуля, имеют место измененные данные, нужно пересчитывать агрегат - если не удается эксклюзивно заблокировать ^BlaBla значит исходные данные находятся в незавершенной транзакции, то есть закешированный результат использовать нельзя. Всем спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.05.2019, 13:40 |
|
|
start [/forum/topic.php?fid=39&msg=39808206&tid=1556191]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
35ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
others: | 273ms |
total: | 392ms |
0 / 0 |