Баг inventTable - DAX: Программирование

Eldar9x · 19.03.2009, 14:12

На всякий случай напишу все подробно.
В методе InventTable.insert() super() обрамлен транзакцией.
Есть у меня класс (от RunBaseBatch), в котором суть метода run() примерно такова:

X++:

try
{
ttsbegin;

while ()
{
this.process(container);
}

ttscommit;
}
catch
{
throw error();
}

Метод process(container) переопределен в наследниках этого класса.
В одном из таких классов происходит заполнение InventTable:

X++:

void process(container)
{
// ....

inventTable.insert();

if (- )
 throw error();

//....
}

Изначально InventTable пуста. После того, как отработает этот throw, возникает следующая ситуация. Запрос

X++:

select firstonly inventTable
where inventTable.ItemId == "Первое значение в имп. файле";

Возращает, невставленную на самом деле, запись. Так как throw отработал, то запись в базу не попадает. Это можно увидеть, сделав прямой запрос в базу.
Что удивительно:

X++:

select firstonly inventTable;

тоже ничего не возвращает.

Первый запрос (с условием) начинает нормально работать только если перезагрузить аос. Как это исправить?

**mazzy** · 19.03.2009, 14:25

Спасибо.
Добавил к теме теги "Баг", "ошибка".

Цитата:

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

На всякий случай напишу все подробно.

а в какой версии проявляется?

**mazzy** · 19.03.2009, 14:27

Цитата:

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

Первый запрос (с условием) начинает нормально работать только если перезагрузить аос. Как это исправить?

Какие параметры кэширования у вас установлены для этой таблицы?

Logger · 19.03.2009, 14:27

Может быть кеш дурит ?
Попробуйте перед выборкой сделать

X++:

inventTable.disableCache(true);

Eldar9x · 19.03.2009, 14:42

Цитата:

Какие параметры кэширования у вас установлены для этой таблицы?

Found.
Сравнение слоев показывает, что изменены только:
ModifiedDate #Yes
ModifiedTime #Yes
ModifiedBy #Yes
CreatedDate #Yes
CreatedTime #Yes
CreatedBy #Yes

AX3.0 sp5 fp2 (Oracle 10g)

Цитата:

Может быть кеш дурит ?
Попробуйте перед выборкой сделать

не помогает....

**mazzy** · 19.03.2009, 15:01

Цитата:

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

Сравнение слоев показывает, что изменены только:

Ну при чем здесь "изменены"?
По-умолчанию у этой таблицы свойство CacheLookup = found.
В хелпе написано.

Цитата:

All successful caching key selects are cached. All caching key selects are returned from cache if the record exists there. A select forupdate in TTS will force reading from the database and replaces the record in the cache.

This is typically used for static tables like ZipCodes where the normal case is that the record exists.

вы сделали insert. запись помещена в кэш. поэтому запрос и возвращает.

не очень понимаю, почему у вас не работает disableCache. в принципе должен. либо вы его не туда поместили. либо он на самом деле не работает в Оракле.

Logger · 19.03.2009, 15:08

Может транзакция на момент перечитывания каким то чудом не откатилась ?

Что говорит appl.ttsLevel() ?

Eldar9x · 19.03.2009, 15:10

Цитата:

Ну при чем здесь "изменены"?
По-умолчанию у этой таблицы свойство CacheLookup = found.

так я же и ответил:

Цитата:

Цитата:

Какие параметры кэширования у вас установлены для этой таблицы?

Found.
Сравнение слоев показывает, что изменены только:
ModifiedDate #Yes
ModifiedTime #Yes
...

**mazzy** · 19.03.2009, 15:17

Цитата:

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

так я же и ответил:
Цитата:

Протормозил. Извините. Подумал, что вы нашли вот такие изменения...

Eldar9x · 19.03.2009, 15:25

Цитата:

Может транзакция на момент перечитывания каким то чудом не откатилась ?

Что говорит appl.ttsLevel() ?

на throw как и положено = 0. К тому же я пробовал из внешнего джоба запрос делать. Все то же...

Eldar9x · 19.03.2009, 15:35

В принципе до вставки записи в базу можно не проверять (так как это не работает)

X++:

        inventTable = null;
        inventTable.clear();
        inventTable.initValue();

        if (InventTable::exist(sCode))
             throw error(strfmt("Запись существует", sCode));

А положиться на уникальный индекс по itemId. С другой стороны, если в данной точке, мне нужно проверить другое поле, причем оно должно быть неуникальным, то добавить уникальный индекс я не могу.

Цитата:

A select forupdate in TTS will force reading from the database and replaces the record in the cache.

делать forupdate, когда он мне не нужен, тоже как-то некрасиво...

еще чудеса. InventTable::exist(sCode) может выдать, что сущ. не первая запись, а скажем 14-я

petr · 19.03.2009, 15:50

Цитата:

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

делать forupdate, когда он мне не нужен, тоже как-то некрасиво...

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

Для примера можно посмотреть классы работы с журналами главной книги - ledgerJournalEngine - например.

Eldar9x · 19.03.2009, 15:56

ура, нашел. flush inventTable; и все путем

Logger · 19.03.2009, 16:30

Цитата:

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

ура, нашел. flush inventTable; и все путем

Значит кеш.
Почему же у вас disableCache(true) не помог ?
Такого не должно быть.

Как вы его использовали ?

Eldar9x · 19.03.2009, 16:38

Цитата:

Как вы его использовали ?

X++:

 inventTable = null;
        inventTable.clear();
        inventTable.initValue();

inventTable.disableCache(true) 
        if (InventTable::exist(sCode))
             throw error(strfmt("Запись существует", sCode));

есть подозрение, что если перенести это в InventTable::exist (что, разумеется делать, не стоит)
или делать запрос по курсору inventTable прямо в методе, то это тоже сработает. Завтра проверю.

Цитата:

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

Для примера можно посмотреть классы работы с журналами главной книги - ledgerJournalEngine - например.

не только поэтому. Пример: Проверяются два поля. Соответственно нужно два курсора. Если при проверке окажется, что выбралась одна и та же запись, получим блокировку. Не проверял, но рисковать не хочется.

Logger · 19.03.2009, 17:05

Правильное подозрение

Проще в данном случае код из Exist() вытащить.

Maximin · 19.01.2010, 17:16

Наступил на те же грабли, но в AX 4.0 SP2.
Пытаюсь импортировать данные группой определений, одна из таблиц - UnitConvert (с режимом кэширования EntireTable). В результате импорта (есть доработка, которая всю сессию импорта проводит в одной транзакции), и вылетания в середине импорта ошибки по throw(), получаем, что изменения в других, "нормальных" таблицах откатились, а в UnitConvert видны записи, которые вставлялись туда импортом. Ессно, в самой базе таких записей нет, но при попытке импортировать заново - выпадает сообщение о уже существующих записях (срабатывает SysDataImportDefBase.findFromKeyData.
Добавление же в него

X++:

    common = new DictTable(_tableId).makeRecord();
    flush common;

, либо _forUpdate = true ситуации не исправляет, т.к. по-видимому, первое сбрасывает кэш клиента, а не AOS, а второе не смущает режим EntireTable. Зато ситуацию отлично исправляет Menuitem SysFlushData с модификатором Server. Т.е. мешает кэш на AOS.
Сбрасывать весь кэш AOSа при начале импорта или его неуспешном окончании из-за какого-то товарища, неправильно заполнившего импортные таблицы как-то не комильфо.
Есть ли другие способы решения?

Maximin · 19.01.2010, 18:18

Пока сделал тупо - перед импортом и после него (метод SysDataImportDefBase.importTable) очередной таблицы делает вызов серверного static метода с упомянутыми выше двумя строками, точнее Dictionary::dataFlush(_tableId). Работает.
Но как ни странно - после неудачного импорта (падает на другой таблице, в UntiConvert к тому времени всё уже залито нормально) вставленные в UnitConvert строки все равно видны, т.е. уже после вставки записей кэш все равно не очищается?!
В общем, как бы то ни было, при повторных запусках записи ищутся/не ищутся правильно. Принцип идемпотентности почти соблюден.

Logger · 19.01.2010, 22:15

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

Хороший повод написать запрос в MBS на исправление.

Думаю что можно просто сбрасывать серверный кеш перед импортом и при перехвате ошибки. Издержки не так велики - это ведь не редактирование записи, а достаточно редкий массовый импорт. Тем более что кеш можно сбросить для конкретной таблицы (если не ошибаюсь - SysFlushData для всех сбросит - это слишком убойный вариант) в нашем случае достаточно выполнить flush common на сервере.

kashperuk · 20.01.2010, 01:38

Я думаю, что это очень сложно грамотно исправить на уровне МС.
Пришлось бы каким-то образом отслеживать на уровне ядра, какие записи вставлялись в этой транзакции, и удалять из кэша только эти записи - ведь прост очищать кэш тоже не очень кошерно

Похожие темы
Тема	Автор	Раздел	Ответов	Посл. сообщение
Баг стандартного механизма перекрытия лукапа	miklenew	DAX: Программирование	5	09.04.2009 14:40
Не корректно сохраняет запись в inventTable	Starling	DAX: Программирование	8	31.03.2008 15:30
reNameItemId для InventTable	DreamCreator	DAX: Программирование	9	26.12.2006 10:11
Программно записи в InventTable	djoker	DAX: Программирование	8	02.12.2004 16:59
Не отображается товары в Form\InventTable!	Zelenhof	DAX: Программирование	6	15.01.2003 17:55