Цитата:
Сообщение от
itfs
Спасибо. А как насчет моего вопроса о времени синхронизации AOS-ов? Вы сознательно проигнорировали это слабое место в архитектуре или просто не понимаете в чем проблема?
С уважением, itfs.
Уважаемый itfs, сознательно отвечаю
на ваш вопрос относительно "слабого места в архитектуре".
Во-первых, хотелось бы удостовериться, что вам известно о существовании и, собственно, содержимом документа AX-300-TIP-058-v01.00-ENUS.doc "
Asynchronous Cache Flushing in Microsoft Business Solutions–Axapta 3.0 SP2", входящего в стандартую поставку 3.0 SP2. Во-вторых, о существовании KR1 (Kernel Rollup 1) для 3.0 SP2, SP3 и SP4, в fixlist'е которого есть пункт
Request No. 2273, KB 899105
Short Description:
Inconsistent caching in multi-client environments:
1) Flushing of the list of dirty records in the AOS cache is not happening in some circumstances.
2) AOS servers in a cluster do not synchronize to the latest flush list at appropriate time intervals.
Detailed Description
Problem
The bug is caused by incorrect use of Windows API GetTickCount. GetTickCount was being used to calculate the elapsed time between 2 points.
GetTickCount() actually returns the number of milliseconds that have elapsed since the system was started. The elapsed time is stored in a 32-bit signed integer. Therefore, the time will wrap around to zero if the system (physical machine) is run continuously for 49.7 days.
Storing the elapsed time in an unsigned integer is not a solution because it works for only one wrap-around. After that, it is broken.
· Solution
The kernel was modified to use an unsigned 64-bit integer value and the monotonically increasing SYSTEM TIMER to compute the elapsed time between 2 points. The AOS periodically refreshes the time by:
1. Synchronizing with a time source
2. Forcing a dirty record flush based on the configured CACHESYNCTIME
3. Resetting the timer
В-третьих, наше тестирование, как указано в нашем отчете http://www.columbusit.ru/Admin/Publi...ax3_(_)_ru.pdf, производилось на ядре build 1951.3885, которое, хоть и не является KR1, но содержит данные важные испавления, связанные со сбросом кэша по CACHESYNCTIME. Само значение CACHESYNCTIME при тестировании мы оставили по умолчанию (60 сек.) и никаких проблем с целостностью, либо с актуальностью данных обнаружено не было.
itfs, следите за обновлениями софта (проверяйте свои доводы почаще), скоро будем говорить о 4.0!
Anatoly Ermakov | Director, Solution Development Office
Columbus IT | Kozhevnichesky pr. 4-8 | 115114 Moscow | Russia
Email:aerm@ru.columbusit.com | Internet: www.columbusit.com