#oracle #caching #oracle-coherence
#Oracle #кэширование #oracle-согласованность
Вопрос:
Я настроил кэш ближней схемы в соответствии с локальной фронтальной схемой и удаленной обратной схемой.
Я думаю, что конфигурация правильная, но я хочу быть уверенным, что она проверяет передний кэш перед обратным.
Как я могу это проверить? Я использую Windows.
Моя конфигурация выглядит так:
<?xml version="1.0"?>
<cache-config xmlns="http://schemas.tangosol.com/cache">
<caching-scheme-mapping>
<cache-mapping>
<cache-name>common-cache</cache-name>
<scheme-name>near-cache</scheme-name>
</cache-mapping>
</caching-scheme-mapping>
<caching-schemes>
<near-scheme>
<scheme-name>near-cache</scheme-name>
<invalidation-strategy>all</invalidation-strategy>
<front-scheme>
<local-scheme>
<scheme-ref>local</scheme-ref>
</local-scheme>
</front-scheme>
<back-scheme>
<remote-cache-scheme>
<scheme-ref>remote</scheme-ref>
</remote-cache-scheme>
</back-scheme>
</near-scheme>
<remote-cache-scheme>
<scheme-name>remote</scheme-name>
<service-name>ExtendTcpCacheService</service-name>
<initiator-config>
<tcp-initiator>
<remote-addresses>
<socket-address>
<address>xxx.xxx.xxx.com</address>
<port>555</port>
</socket-address>
</remote-addresses>
<connect-timeout>5s</connect-timeout>
</tcp-initiator>
<outgoing-message-handler>
<request-timeout>30s</request-timeout>
</outgoing-message-handler>
<serializer>
<class-name>Tangosol.IO.Pof.ConfigurablePofContext, Coherence</class-name>
<init-params>
<init-param>
<param-type>string</param-type>
<param-value>web://~/coherence-pof-config.xml</param-value>
</init-param>
</init-params>
</serializer>
</initiator-config>
</remote-cache-scheme>
<local-scheme>
<scheme-name>local</scheme-name>
<eviction-policy>HYBRID</eviction-policy>
<high-units>1000</high-units>
<low-units>750</low-units>
<unit-calculator>FIXED</unit-calculator>
<expiry-delay>10d</expiry-delay>
<flush-delay>1d</flush-delay>
</local-scheme>
</caching-schemes>
</cache-config>
Ответ №1:
Вы можете попробовать следующее:
установить:
<invalidation-strategy>None</invalidation-strategy>
Эта стратегия предписывает кешу вообще не прослушивать события аннулирования. Это лучший выбор для обеспечения исходной производительности и масштабируемости, когда бизнес-требования позволяют использовать данные, которые могут быть не совсем актуальными. Свежесть данных может быть гарантирована использованием достаточно краткой политики удаления для фронтального кэша http://docs.oracle.com/cd/E18686_01/coh.37/e18677/cache_config.htm
- добавить запись в кэш
- запись обновления от второго клиента
- убедитесь, что первый клиент имеет неизмененную запись
Ответ №2:
«общий кэш» использует схему «ближнего кэша», так что это то поведение, которое вы ищете.
Чтобы проверить это, обратитесь к 100000 различным (и несуществующим) ключам, например, к новому целому числу (1) через новое целое число (100000) и проверьте время. Теперь «вставьте» ключ для целого числа (1), например
cache.put(new Integer(1), "hello world")
а затем повторите первый тест, но вместо доступа от 1 до 100000 просто повторно используйте «новое целое число (1)» — 100 000 раз!
Первый тест может занять минуту или две (в зависимости от того, сколько серверов, находятся ли они на одном компьютере и т. Д.) Второй тест должен занять менее секунды.