Кэширование курсов валют

[Tony Green]

А сталкивался ли кто-нибудь с такой ситуацией в трехуровневой аксе, когда с одной машины поменяли курс валюты, а с других еще пару часов народ формировал документы по старому курсу?

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

[EVGL]

Если вы меняете курс в форме Currency, то автоматически из метода write() вызывается ExchRates::exchRateCache(true) => flush.

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

[Tony Green]

вызываться-то он вызывается. и мужественно отрабатывает очищая кэш. Только это не настоящий аксаптовский кэш, а кэш в переменной класса ClassFactory. А у каждого пользователя свой экземпляр этого класса. Вот и получается, что у них курс еще какое-то время старый. Или я ошибаюсь?

[EVGL]

Да, вы правы. Коллизия не исключена, поскольку ClassFactory существует в двух "ипостасях": на клиенте и на сервере. flush... очищает кэш на сервере и текущем клиенте. Прослеживая цепочку вызовов, можно видеть что методы Currency::amountCur2MST() -> Currency::exchRate() -> ExchRates::exchRateCache() все объявлены как "Called from". Т.е. описанная вами ситуация вполне может возникнуть, если второй клиент успел запомнить в кеше старое значение и запускает некую функцию, которая работает не на сервере. Баг. Пишите авторам.

[Tony Green]

спасибо за поддержку. дополню:
дело даже не в том, что второй клиент успел запомнить в кэше на клиенте старый курс, а в том, что методы ExchRates::flushCacheServer() и ExchRates::flushCacheClient() очищают переменную класса ClassFactory только ПЕРВОГО клиента, где и была произведена смена курса
В свете этого уже не важно, на клиенте или на сервере выполняется функциональность второго клиента - он так и останется со старым курсом.

Опять же: поправьте меня, если я заблуждаюсь.

[Vadik]

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

[glibs]

Стареешь...

static client server ExchRateCache exchRateCache(boolean reSelect = false)
{
// GLIBS, Disabling exchange rates cache -->
return classFactory.exchRateCache(true);
// return classFactory.exchRateCache(reSelect);
// GLIBS, Disabling exchange rates cache <--
}

Это в табличке ExchRates.

Только в табличке ExchRates имеет смысл после этого смастерить уникальный индекс (primary key). Например, из CurCodeDateIdx его сделать. Чтобы кэширование стандартное (которое на уровне таблицы) работало.

[Vadik]

Цитата:

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

Стареешь...

Ясно, что не молодею
Просто _reselect - первое, что было сделано (quick & dirty)
Но этим дело не ограничилось, так как сбрасывать кэш при каждом обращении к нему как-то неэстетично
Или по крайней мере сейчас, когда есть время подумать, не ограничился бы

[glibs]

Вопрос философский. Ты ведешь речь о переделке движка по работе с курсами. По идее — это правильное с технической т.з. решение. Но я иногда предпочитаю сделать менее технически правильное, но зато (грубо говоря) проще переносимое на новые СП. Принятие решения о том или ином способе решения проблемы зависит от "цены вопроса" (т.е. если производительность возрастет в 2 раза — это одно, если на 2% — другое). Хотя, м.б. там не сложно и так как ты говоришь переделывать — но опять же "цена вопроса". Я привык экономить деньги клиента (без особой надобности лишнего не делать).

Раз уж продолжили, то я поправлюсь. Вчера на глаза попалась дока... Для курсов валют придется поставить кэширование EntireTable. Синхронизация кэша с интервалом в 60 сек. работает только для этого режима кэширования (в доке так написано).