Работа с TempDB-таблицами

[mazzy]

Цитата:

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

Где правильнее всего разместить этот вызов ?
Напрашивается
\Classes\Application\closingDown

при падении Аксапты кэш не будет очищен.

"некий кеш" лучше организовывать при помощи стандартного кэш сервера. например Redis.
В том же Redis есть автопротухание данных.

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

[Logger]

Цитата:

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

при падении Аксапты кэш не будет очищен.

Это да.
Но я и не надеялся такое вылечить. Не все под силу.
Там много г. во временной базе остается при падении аоса.

Это у меня не совсем кеш. Я не совсем корректный термин употребил. В общем времянка хранит некие данные актуальные только для конкретного юзера. Т.е. у каждого юзера свое наполнение.

Соответственно вопрос, с учетом багов ядра по освобождению времянок, куда корректно было бы поместить вызов dispose() для времянки.

Может кто делал и проверял как работает.
Интересно также CIL сессии и те, что создаются по RunAs. Для них ядро вызывает closingDown ?

Хотелось остаться внутри аксапты и не привлекать сторонние инструменты (Redis, etc)

[fed]

Мне кажется что проблема зависших времянок в tempDb не так страшна. Когда AOS будет останавливаться, времянки удалятся.
Проблема с времянками в том, что если ты их в цикле создаешь, а потом через dispose() не освобождаешь, то кэш плана запроса забивается тысячам одинаковых запросов, у которых только имя временной таблицы отличается. В твоем случае гарантируется что всего один инстанц времянки на пользователя будет и даже если пользователь из системы выйдет, а времянка не удалится, то новых запросов в кэше по ней появлятся не будет. То есть - я бы с этой проблемой просто не стал бы бороться.

[Logger]

Да, циклов там не будет.
Согласен, что несущественная проблема.
Просто все мы стремимся к идеалу, хоть чуть-чуть.

Вот и возникает вопрос.
А как бы правильно ...

[fed]

Опыт показал, что если в классе создать переменную типа tempDB, положить туда данные, потом FormDataSource прикрепить к этому же инстанцу временной таблицы через myDataSource_ds.cursor().linkPhysicalTableInstance(MyCalculationClass.tempDbBuffer()), а потом вызвать для исходных табличных переменных из MyCalculationClass метод Dispose(), то последствия бывают самые интересные и не вполне предсказуемые. В том числе иногда падает Productive AOS
Я так понимаю, когда форма закрывается, переменные с датасорцами не освобождаются немедленно, а ждут сборки мусора. Потом в какой-то момент времени сборщик мусора просыпается, пытается удалить датасорцы и прикрепленные к ним табличные переменные, а там опаньки - табличные переменные-то уже кто-то удалил. В итоге сервер с заметной вероятностью падает.
В общем - похоже что после linkPhysicalTableInstance() вызывать Dispose для табличных переменных просто нельзя.
P.S. D365FO. Но я подозреваю что в DAX2012 грабли аналогичной конструкции.

[Raven Melancholic]

Цитата:

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

Опыт показал, что если в классе создать переменную типа tempDB, положить туда данные, потом FormDataSource прикрепить к этому же инстанцу временной таблицы через myDataSource_ds.cursor().linkPhysicalTableInstance(MyCalculationClass.tempDbBuffer()), а потом вызвать для исходных табличных переменных из MyCalculationClass метод Dispose(), то последствия бывают самые интересные и не вполне предсказуемые. В том числе иногда падает Productive AOS
...
В общем - похоже что после linkPhysicalTableInstance() вызывать Dispose для табличных переменных просто нельзя.
P.S. D365FO. Но я подозреваю что в DAX2012 грабли аналогичной конструкции.

Да, совсем недавно на 2012 с этим столкнулся.
Правда у меня падает не АОС, а клиент и не через некоторое время, а практически сразу при закрытии формы.

Но и кейс немного другой, я вызываю linkPhysicalTableInstance не на датасорсе, а наоборот, передаю курсор датасорса и его прикрепляю к локальной переменной:

public void inventToShipPrepare(
    ShipmentJournalRequestMap_OVK   _journalRequest,
    ShipmentInventToShipMap_OVK     _inventToShip
    )
{
    ShipmentInventToShipMap_OVK         inventToShip;
    ;
    
    inventToShip        = _inventToShip.emptyRecord();
    if (_inventToShip.isTempDb())
    {
        inventToShip.linkPhysicalTableInstance(_inventToShip);
    }

...

    // TODO: AKlim 12.10.2022 Попробовать разобраться в причине падения клиента
    //       Пока освобождение закомментировано, так как падает клиент при закрытии формы
    /*    
    if (_inventToShip.isTempDb())
    {
        inventToShip.dispose();
    }
    */
}

[Logger]

Крайне неприятный баг.
Использованные вами методы работают со ссылкой на переменную. Возможно из-за этого дополнительные зависимости появляются и поэтому падает.

А если задействовать методы ?
getPhysicalTableName
useExistingTempDBTable

Там просто реальное SQL имя таблички передается.
Возможно не будет падать.
Я в своей модификации использовал их - не падало. Правда сценарий был немного другой.

[fed]

Цитата:

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

Крайне неприятный баг.
...
А если задействовать методы ?
getPhysicalTableName
useExistingTempDBTable

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

[bio_unit]

То, что сервер роняет - это еще ничего...
Мы столкнулись на D365, что при неумелом использовании dispose и передаче tempDb таблиц через простое присваивание переменных, может быть эффект удаления данных из реальных таблиц БД.

delete_from tmpSomeTable;

Видимо, когда сборщик мусора отрабатывает, то tmpSomeTable может ссылать на какой-то произвольный курсор, какой-то случайной таблицы и delete_from отрабатывает по какой-то произвольной физической таблице БД.
Например, в одном случае - CustParameters, в другом - InventTable.
Из таблиц БД начинают "загадочно" пропадать данные.

[Logger]

Цитата:

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

То, что сервер роняет - это еще ничего...
Мы столкнулись на D365, что при неумелом использовании dispose и передаче tempDb таблиц через простое присваивание переменных, может быть эффект удаления данных из реальных таблиц БД.

А как лечили ?

Убирали

delete_from tmpSomeTable;

Отказались от dispose ?