|
12.05.2006, 12:18 | #1 |
Участник
|
Блокировки. Интересный эффект.
Ситуация следующая:
1. Запускаем разноску складского журнала и где-нибудь внтури транзакции ее тормозим через дебаггер (например, перед ttscommit). 2. В другой сессии заходим в форму складских журналов. В форму заходим без проблем, видим заблокированный для разноски журнал, бегаем по другим журналам - все ок. Но если встать на какой-нибудь журнал рядом с заблокированным журналом и "постоять" там некоторое время возникает блокировка на InventJournalTable. Зачем-то система запускает еще один процесс, которому уже нужны не UNCOMITTED данные (как во время открытия формы складских журналов), а COMMITTED. Что это за процесс и зачем нужен - пока не выяснил. Что по этому поводу имеет сказать многоуважемый ALL? Последний раз редактировалось Косых Артём; 12.05.2006 в 12:48. |
|
12.05.2006, 13:01 | #2 |
NavAx
|
Происходит это из-за JournalFormTable.formMethodTimeOutRedraw
Этот метод обновляет визуально форму журнала (помоему раз в 30 секунд). Т.е. если один пользователь разнёс журнал, то другой спустя какое-то время увидит что журнал разнесён. Полезно при пакетной обработке - можно увидеть когда журнал разнёсся. Лечится просто: Код: ttsBegin; journalTableTmp = journalTableData.JournalStatic().findJournalTable(journalTableFormCache.journalId,true); ttsCommit; Сталкивался с ситуацией - пользователь при каких-то условиях блокировал сам себя наглухо - после чего решил это подправить.
__________________
С уважением, Игорь Ласийчук. |
|
|
За это сообщение автора поблагодарили: George Nordic (5), Косых Артём (1). |
|
Похожие темы | ||||
Тема | Ответов | |||
блокировки таблицы WMTRANSFER_FACTUREJOUR. | 0 | |||
Неясные блокировки | 1 | |||
Мертвые блокировки при резерве | 36 | |||
Интересный эффект при накате KR1 | 4 | |||
Блокировки | 8 |
|