Классы от RunBaseReport и класс Thread

[Logger]

Поделюсь одним изысканием по поводу Thread

Недавно обнаружил, что при изменении данных сторонними средствами в EntireTable кешируемых табличках или при выполнении к таким табличкам прямых запросов SQL на обновление - кеш не только видит этих изменений, но и не хочет сбрасываться обычными способами. (Подчеркну - речь идет именно о прямых запросах SQL к базе, формируемых например при дублировании компаний класом SysSqlCopyCompany)
Эта особенность в 2009-й Аксапте особено опасна тем что аосы можно долго не перестартовывать (в отличие от трешки). У нас, например, пакетный сервер неделями может без перестарта жить.

Попробовал сбрасывать кеш вызовом Меню-Сервис-Средства разработки-Объекты приложения-Обновить данные

Не работает. После некоторых разбирательств выяснилось, что необходимо сбрасывать именно серверный кеш. Поправили менюитем SysFlushData -на одном аосе все ок. А в кластере аосов все равно кеш не сбрасывается.

Вместе с тем при вызове класса по менюитему SysFlushData - пишется информация в лог SysEvent, который должны читать служебные сессии на других аосах и обрабатывать сброс кеша. (Класс SysEventHandler )

Но как видно из этого примера, ожидаемой обработки лога SysEvent не происходит.

После некоторых разбирательств удалось понять, что при старте АОСа он создает 2 системные сессии с SessionID равным 1 и 2.
В каждой из этих сессий при вызове Application.new() происходит вызов SysEventHandler::initialize();

Далее идет попытка создать отдельный поток при помощи класса Thread и в нем запустить на выполнение статический метод SysEventHandler::runHandler таким вызовом

    thread.run(classnum(SysEventHandler),staticmethodstr(SysEventHandler,runHandler));

Но этого, к сожалению не происходит ! Код метода runHandler не исполняется (проверял по записи в файл на диске. Добавил в метод runHandler пару строк кода, пишущих лог на диск.)
Т.е. обработчик событий не работает и кеши на аосах в кластере не сбрасываются. (Также возможно не сбрасывается кеш AOT и словаря и настройки логирования sysDatabaseLog - детально проверить руки не дошли.)

Если же извратиться и из джоба запустить таки описанный обработчик, например так
SysEventHandler::initialize(true);
то все же можно заставить работать данный обработчик. В этом случае при вызове

    thread.run(classnum(SysEventHandler),staticmethodstr(SysEventHandler,runHandler));

отдельный поток на сервере создается и код в нем исполняется. И текстовый лог на диске тоже пишется. (Чтобы код работал без ошибок пришлось еще сделать некоторые добавления в метод runHandler, связанные с permission.assert(); но это непринципиально)

Но! Работает он все равно как-то глючно.
Например если в SysEvent послать событие SysEventType::EventHandlerPing то оно успешно обработается и в ответ отправится событие SysEventType::EventHandlerAlive
Так что если из 3-ки в 2009-й поднять форму SysEventManagement, то в ней как раз можно увидеть результаты использования этих событий - она успешно опрашивает все работающие аосы в кластере и выводит их перечень.

Но если послать событие SysEventType::FlushData - а именно оно и отправляется при сбросе кеша, то почему-то в силу невыясненных причин кеш не сбрасывается. Т.е. код работает но как то "не до конца" Т.е. если на сервере запускается код

Dictionary::dataFlush();

из под обычной пользовательской сессии, то все в порядке - кеш табличек сбрасывается. А если этот же код запускается на сервере в отдельном потоке, созданном при помощи класса Thread - то кеш не сбрасывается. Чудеса...

P.S.
Ax2009 build 4570 (RU7)
Приложение RU5

Кстати, кто-нибудь умеет гарантированно сбрасывать кеш табличек в кластере аосов ?
Поделитесь.

[Pustik]

Спасибо всем, я понимаю так, что это не лучшее решение.

[Logger]

Цитата:

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

После некоторых разбирательств удалось понять, что при старте АОСа он создает 2 системные сессии с SessionID равным 1 и 2.

Какая жесть
Оказывается они еще и ведут себя по разному.
Сессия 1 считает что curExt() = "" !
Как следствие, если захочется что-то по логировать то для нее не получится это сделать (поймать момент старта аоса и записать в табличный лог). Тупо выдает ошибку

Цитата:

Object Server XX: Dialog issued for client-less session 1: Cannot create a record in YYYYYYY (ZZZZZ).
Insert operations are not allowed across companies. Please use changecompany keyword to change the current company before inserting the record.

Зато для пакетной сессии 2 все нормально работает. Какая-то жесть