Проверка согласованности вблизи схемы

#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 раз!

Первый тест может занять минуту или две (в зависимости от того, сколько серверов, находятся ли они на одном компьютере и т. Д.) Второй тест должен занять менее секунды.