anchor.diff:  Additionally, when removing a {prodname} Oracle connector that uses the Infinispan buffer, the persisted cache files are not removed from disk automatically.
   If the same buffer location will be used by a new connector deployment, the files should be removed manually before deploying the new connector.
   ====
  +
  +===== Infinispan Hotrod client integration
  +
  +The {prodname} Oracle connector utilizes the Hotrod client to communicate with the Infinispan cluster.
  +Any connector property that is prefixed with `log.mining.buffer.infinispan.client.` will be passed directly to the Hotrod client using the `infinispan.client.` namespace, allowing for complete customization of how the client is to interact with the cluster.
  +
  +There is at least one required configuration property that must be supplied when using this Infinspan mode:
  +
  +`log.mining.buffer.infinispan.client.hotrod.server_list`::
  +Specifies the list of Infinispan server hostname and port combinations, using `<hostname>:<port>` format.
   endif::community[]
   
   // Type: concept
  
positive.code: The infinispan option requires that you specify a cache file directory.
  Use the `log.mining.buffer.location` property to define the location for storing cache files.
  
  |[[oracle-property-log-mining-buffer-location]]<<oracle-property-log-mining-buffer-location, `+log.mining.buffer.location+`>>
  |No default
  |Specifies the location of the directory that the connector uses to read and write the buffer cache.
  Specify a directory that every node in the Kafka cluster can access and that is unique for the connector deployment.
  endif::community[]
  
  |[[oracle-property-log-mining-buffer-drop-on-stop]]<<oracle-property-log-mining-buffer-drop-on-stop, `+log.mining.buffer.drop.on.stop+`>>
  |`false`
  
negative.code: 
  You can configure the buffering mechanism that the connector uses by setting the property xref:oracle-property-log-mining-buffer-type[`log.mining.buffer.type`].
  
  ==== Heap
  The default buffer type is configured using `memory`.
  Under the default `memory` setting, the connector uses the heap memory of the JVM process to allocate and manage buffered event records.
  If you use the `memory` buffer setting, be sure that the amount of memory that you allocate to the Java process can accommodate long-running and large transactions in your environment.
  
  ifdef::community[]
  [[oracle-event-buffering-infinispan]]
  ==== Infinispan
  The {prodname} Oracle connector can also be configured to use Infinispan as it's cache provider, supporting cache stores both locally with embedded mode or remotely on a server cluster.
  In order to use Infinispan, the xref:oracle-property-log-mining-buffer-type[`log.mining.buffer.type`] must be configured using either `infinispan_embedded` or `infinispan_remote`.
  
  In order to allow flexibility with Infinispan cache configurations, the connector expects a series of cache configuration properties to be supplied when using Infinispan to buffer event data.
  
  `log.mining.buffer.infinispan.cache.transactions`::
  Specifies the XML configuration for the transaction cache.
  `log.mining.buffer.infinispan.cache.events`::
  Specifies the XML configuration for the event cache.
  `log.mining.buffer.infinispan.cache.committed_transactions`::
  Specifies the XML configuration for the committed transactions cache.
  `log.mining.buffer.infinispan.cache.rollback_transactions`::
  Specifies the XML configuration for the rollback transactions cache.
  `log.mining.buffer.infinispan.cache.schema_changes`::
  Specifies the XML configuration for the schema changes cache.
  
  The contents of each of these configuration properties depend on whether the connector is to integrate with a remote Infinispan cluster or to use the embedded engine.
  
  For example, the following illustrates what an embedded configuration would look like for the transaction cache property when using Infinispan in embedded mode:
  
  [source,xml]
  ----
  <local-cache name="transactions">
    <persistence passivation="false">
      <file-store fetch-state="true" read-only="false" preload="true" shared="false" segmented="false" path="./data" />
    </persistence>
  </local-cache>
  ----
  
  Looking at the configuration in-depth, the cache is configured to be persistent.
  All caches should be configured this way to avoid loss of transaction events across connector restarts if a transaction is in-progress.
  Additionally, the location where the cache is kept is defined by the `path` attribute and this should be a shared location accessible all possible runtime environments.
  
  Another example, the following illustrates the same cache configured with an Infinispan cluster:
  
  [source,xml]
  ----
  <distributed-cache name="transactions" statistics="true">
    <encoding media-type="application/x-protostream" />
    <persistence passivation="false">
      <file-store fetch-state="true" read-only="false" preload="true" shared="false" segmented="false" />
    </persistence>
  </distributed-cache>
  ----
  
  Just like the embedded local-cache configuration from the previous example, this configuration is also defined to be persistent.
  All caches should be configured this way to avoid loss of transaction events across connector restarts if a transaction is in-progress.
  
  However, there are a few differences with noting.
  First, the cache is defined as a distributed cache rather than a local-cache.
  Secondly, the cache is defined to use the `application/x-protostream` encoding, which is required for all Debezium caches.
  And lastly, no `path` attribute is necessary on the file store definition since the Infinispan cluster will handle this automatically.
  
  [IMPORTANT]
  ====
  