<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!--
  ~ Copyright 2012 Red Hat, Inc. and/or its affiliates.
  ~
  ~ This is free software; you can redistribute it and/or modify it
  ~ under the terms of the GNU Lesser General Public License as
  ~ published by the Free Software Foundation; either version 2.1 of
  ~ the License, or (at your option) any later version.
  ~
  ~ This software is distributed in the hope that it will be useful,
  ~ but WITHOUT ANY WARRANTY; without even the implied warranty of
  ~ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  ~ Lesser General Public License for more details.
  ~
  ~ You should have received a copy of the GNU Lesser General Public
  ~ License along with this library; if not, write to the Free Software
  ~ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
  ~ 02110-1301 USA
  -->

<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" version="1.0" targetNamespace="urn:infinispan:config:5.1" xmlns:tns="urn:infinispan:config:5.1" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="infinispan">
    <xs:annotation>
      <xs:documentation>
        Defines the configuration for Infinispan, for the cache manager configuration, for the default cache, and for named caches.
      </xs:documentation>
    </xs:annotation>
    <xs:complexType>
        <xs:sequence>
        <xs:element name="global">
          <xs:complexType>
            <xs:annotation>
              <xs:documentation>
                Defines global settings shared among all cache instances created by a single CacheManager.
              </xs:documentation>
            </xs:annotation>
            <xs:all>
              <xs:element name="asyncListenerExecutor" type="tns:executorFactory" minOccurs="0">
                <xs:annotation>
                  <xs:documentation>
                    Configuration for the executor service used to emit notifications to asynchronous listeners
                  </xs:documentation>
                </xs:annotation>
              </xs:element>
              <xs:element name="asyncTransportExecutor" type="tns:executorFactory" minOccurs="0">
                <xs:annotation>
                  <xs:documentation>
                    Configuration for the executor service used for asynchronous work on the Transport, including asynchronous marshalling and Cache 'async operations' such as Cache.putAsync().
                  </xs:documentation>
                </xs:annotation>
              </xs:element>
              <xs:element name="evictionScheduledExecutor" type="tns:scheduledExecutorFactory" minOccurs="0">
                <xs:annotation>
                  <xs:documentation>
                    Configuration for the scheduled executor service used to periodically run eviction cleanup tasks.
                  </xs:documentation>
                </xs:annotation>
              </xs:element>
              <xs:element name="replicationQueueScheduledExecutor" type="tns:scheduledExecutorFactory" minOccurs="0">
                <xs:annotation>
                  <xs:documentation>
                    Configuration for the scheduled executor service used to periodically flush replication queues, used if asynchronous clustering is enabled along with useReplQueue being set to true.
                  </xs:documentation>
                </xs:annotation>
              </xs:element>
              <xs:element name="globalJmxStatistics" minOccurs="0">
                <xs:annotation>
                  <xs:documentation>
                    This element specifies whether global statistics are gathered and reported via JMX for all caches under this cache manager.
                  </xs:documentation>
                </xs:annotation>
                <xs:complexType>
                  <xs:sequence>
                    <xs:element name="properties" type="tns:properties" minOccurs="0">
                      <xs:annotation>
                        <xs:documentation>
                          Sets properties which are then passed to the MBean Server Lookup implementation specified.
                        </xs:documentation>
                      </xs:annotation>
                    </xs:element>
                  </xs:sequence>
                  <xs:attribute name="allowDuplicateDomains" type="xs:boolean">
                   <xs:annotation>
                     <xs:documentation>
                       If true, multiple cache manager instances could be configured under the same configured JMX domain. Each cache manager will in practice use a different JMX domain that has been calculated based on the configured one by adding an incrementing index to it.
                     </xs:documentation>
                   </xs:annotation>
                  </xs:attribute>
                  <xs:attribute name="cacheManagerName" type="xs:string">
                   <xs:annotation>
                     <xs:documentation>
                       If JMX statistics are enabled, this property represents the name of this cache manager. It offers the possibility for clients to provide a user-defined name to the cache manager which later can be used to identify the cache manager within a JMX based management tool amongst other cache managers that might be running under the same JVM.
                     </xs:documentation>
                   </xs:annotation>
                  </xs:attribute>
                  <xs:attribute name="enabled" type="xs:boolean">
                    <xs:annotation>
                      <xs:documentation>Enable Global JMX statistics</xs:documentation>
                    </xs:annotation>
                  </xs:attribute>
                  <xs:attribute name="jmxDomain" type="xs:string">
                   <xs:annotation>
                     <xs:documentation>
                       If JMX statistics are enabled then all 'published' JMX objects will appear under this name. This is optional, if not specified an object name will be created for you by default.
                     </xs:documentation>
                   </xs:annotation>
                  </xs:attribute>
                  <xs:attribute name="mBeanServerLookup" type="xs:string">
                   <xs:annotation>
                     <xs:documentation>
                       Class that will attempt to locate a JMX MBean server to bind to
                     </xs:documentation>
                   </xs:annotation>
                  </xs:attribute>
                </xs:complexType>
              </xs:element>
              <xs:element name="transport" minOccurs="0">
                <xs:annotation>
                  <xs:documentation>
                    This element configures the transport used for network communications across the cluster.
                  </xs:documentation>
                </xs:annotation>
                <xs:complexType>
                  <xs:sequence>
                    <xs:element name="properties" type="tns:properties" minOccurs="0">
                      <xs:annotation>
                         <xs:documentation>
                            Sets transport properties
                         </xs:documentation>
                      </xs:annotation>
                    </xs:element>
                  </xs:sequence>
                  <xs:attribute name="clusterName" type="xs:string">
                    <xs:annotation>
                      <xs:documentation>
                         Defines the name of the cluster. Nodes only connect to clusters sharing the same name.
                      </xs:documentation>
                    </xs:annotation>
                  </xs:attribute>
                  <xs:attribute name="distributedSyncTimeout" type="xs:long">
                    <xs:annotation>
                      <xs:documentation>
                        Infinispan uses a distributed lock to maintain a coherent transaction log during state transfer or rehashing which means that only one cache can be doing state transfer or rehashing at the same time. This constraint is in place because more than one cache could be involved in a transaction. This timeout controls the time to wait to acquire acquire a lock on the distributed lock.
                      </xs:documentation>
                    </xs:annotation>
                  </xs:attribute>
                  <xs:attribute name="machineId" type="xs:string">
                    <xs:annotation>
                      <xs:documentation>
                        The id of the machine where this node runs. Visit http://community.jboss.org/wiki/DesigningServerHinting for more information .
                      </xs:documentation>
                    </xs:annotation>
                  </xs:attribute>
                  <xs:attribute name="nodeName" type="xs:string">
                    <xs:annotation>
                      <xs:documentation>
                        Name of the current node. This is a friendly name to make logs, etc. make more sense. Defaults to a combination of host name and a random number (to differentiate multiple nodes on the same host)
                      </xs:documentation>
                    </xs:annotation>
                  </xs:attribute>
                  <xs:attribute name="rackId" type="xs:string">
                    <xs:annotation>
                      <xs:documentation>
                        The id of the rack where this node runs. Visit http://community.jboss.org/wiki/DesigningServerHinting for more information .
                      </xs:documentation>
                    </xs:annotation>
                  </xs:attribute>
                  <xs:attribute name="siteId" type="xs:string">
                    <xs:annotation>
                      <xs:documentation>
                        The id of the site where this node runs. Visit http://community.jboss.org/wiki/DesigningServerHinting for more information .
                      </xs:documentation>
                    </xs:annotation>
                  </xs:attribute>
                  <xs:attribute name="strictPeerToPeer" type="xs:boolean">
                    <xs:annotation>
                      <xs:documentation>
                        If set to true, RPC operations will fail if the named cache does not exist on remote nodes with a NamedCacheNotFoundException. Otherwise, operations will succeed but it will be logged on the caller that the RPC did not succeed on certain nodes due to the named cache not being available.
                      </xs:documentation>
                    </xs:annotation>
                  </xs:attribute>
                  <xs:attribute name="transportClass" type="xs:string">
                    <xs:annotation>
                      <xs:documentation>
                        Class that represents a network transport. Must implement org.infinispan.remoting.transport.Transport
                      </xs:documentation>
                    </xs:annotation>
                  </xs:attribute>
                </xs:complexType>
              </xs:element>
              <xs:element name="serialization" minOccurs="0">
                <xs:annotation>
                  <xs:documentation>
                    Configures serialization and marshalling settings.
                  </xs:documentation>
                </xs:annotation>
                
                <xs:complexType>
                  <xs:sequence>
                    <xs:element name="advancedExternalizers" minOccurs="0">
                      <xs:annotation>
                        <xs:documentation>
                          Configures custom marshallers.
                        </xs:documentation>
                      </xs:annotation>
                        <xs:complexType>
                          <xs:sequence>
                            <xs:element name="advancedExternalizer" minOccurs="0" maxOccurs="unbounded">
                              <xs:annotation>
                                <xs:documentation>
                                  AdvancedExternalizer provides an alternative way to provide externalizers for marshalling/unmarshalling user defined classes that overcome the deficiencies of the more user-friendly externalizer definition  model explained in Externalizer.
                                </xs:documentation>
                              </xs:annotation>
                              <xs:complexType>
                                <xs:attribute name="externalizerClass" type="xs:string">
                                  <xs:annotation>
                                    <xs:documentation>
                                      Class of the custom marshaller
                                    </xs:documentation>
                                  </xs:annotation>
                                </xs:attribute>
                                <xs:attribute name="id" type="xs:int">
                                  <xs:annotation>
                                    <xs:documentation>
                                      Id of the custom marshaller
                                    </xs:documentation>
                                  </xs:annotation>
                                </xs:attribute>
                              </xs:complexType>
                            </xs:element>
                          </xs:sequence>
                        </xs:complexType>
                    </xs:element>
                  </xs:sequence>
                  <xs:attribute name="marshallerClass" type="xs:string">
                   <xs:annotation>
                      <xs:documentation>
                         Fully qualified name of the marshaller to use. It must implement org.infinispan.marshall.StreamingMarshaller
                      </xs:documentation>
                   </xs:annotation>
                  </xs:attribute>
                  <xs:attribute name="version" type="xs:string">
                   <xs:annotation>
                      <xs:documentation>
                         Largest allowable version to use when marshalling internal state. Set this to the lowest version cache instance in your cluster to ensure compatibility of communications. However, setting this too low will mean you lose out on the benefit of improvements in newer versions of the marshaller.
                      </xs:documentation>
                   </xs:annotation>
                  </xs:attribute>
                </xs:complexType>
              </xs:element>
              <xs:element name="shutdown" minOccurs="0">
                <xs:annotation>
                  <xs:documentation>
                    This element specifies behavior when the JVM running the cache instance shuts down.
                  </xs:documentation>
                </xs:annotation>
                <xs:complexType>
                  <xs:attribute name="hookBehavior" type="tns:shutdownHookBehavior">
                    <xs:annotation>
                      <xs:documentation>
                        Behavior of the JVM shutdown hook registered by the cache
                      </xs:documentation>
                    </xs:annotation>
                  </xs:attribute>
                </xs:complexType>
              </xs:element>
            </xs:all>
          </xs:complexType>
        </xs:element>
        <xs:element name="default" type="tns:configuration" minOccurs="0">
          <xs:annotation>
            <xs:documentation>
              Specifies the default behvaior for all named caches belonging to this cache manager.
            </xs:documentation>
          </xs:annotation>
        </xs:element>
        <xs:element name="namedCache" type="tns:configuration" minOccurs="0" maxOccurs="unbounded">
          <xs:annotation>
            <xs:documentation>
              Specify the configuration for a named cache.
            </xs:documentation>
          </xs:annotation>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  
  <xs:complexType name="configuration">
    <xs:all>
      <xs:element name="locking" minOccurs="0">
        <xs:annotation>
          <xs:documentation>
            Defines the local, in-VM locking and concurrency characteristics of the cache.
          </xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="concurrencyLevel" type="xs:int">
            <xs:annotation>
              <xs:documentation>
                Concurrency level for lock containers. Adjust this value according to the number of concurrent threads interacting with Infinispan. Similar to the concurrencyLevel tuning parameter seen in the JDK's ConcurrentHashMap.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="isolationLevel" type="tns:isolationLevel">
            <xs:annotation>
              <xs:documentation>
                Cache isolation level. Infinispan only supports READ_COMMITTED or REPEATABLE_READ isolation levels. See http://en.wikipedia.org/wiki/Isolation_level'>http://en.wikipedia.org/wiki/Isolation_level for a discussion on isolation levels.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="lockAcquisitionTimeout" type="xs:long">
            <xs:annotation>
              <xs:documentation>
                Maximum time to attempt a particular lock acquisition
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="useLockStriping" type="xs:boolean">
            <xs:annotation>
              <xs:documentation>
                If true, a pool of shared locks is maintained for all entries that need to be locked. Otherwise, a lock is created per entry in the cache. Lock striping helps control memory footprint but may reduce concurrency in the system.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="writeSkewCheck" type="xs:boolean">
            <xs:annotation>
              <xs:documentation>
                This setting is only applicable in the case of REPEATABLE_READ. When write skew check is set to false, if the writer at commit time discovers that the working entry and the underlying entry have different versions, the working entry will overwrite the underlying entry. If true, such version conflict - known as a write-skew - will throw an Exception.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <xs:element name="loaders" minOccurs="0">
        <xs:annotation>
          <xs:documentation>
            Configuration for cache loaders and stores.
          </xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:sequence>
            <xs:element name="loader" minOccurs="0" maxOccurs="unbounded">
              <xs:annotation>
                <xs:documentation>
                  Configuration a specific cache loader or cache store
                </xs:documentation>
              </xs:annotation>
              <xs:complexType>
                <xs:all>
                  <xs:element name="async" minOccurs="0">
                    <xs:annotation>
                      <xs:documentation>
                        Configuration for the async cache loader. If enabled, this provides you with asynchronous writes to the cache store, giving you 'write-behind' caching.
                      </xs:documentation>
                    </xs:annotation>
                    <xs:complexType>
                      <xs:attribute name="enabled" type="xs:boolean">
                        <xs:annotation>
                          <xs:documentation>
                            If true, all modifications to this cache store happen asynchronously, on a separate thread.
                          </xs:documentation>
                        </xs:annotation>
                      </xs:attribute>
                      <xs:attribute name="flushLockTimeout" type="xs:long">
                        <xs:annotation>
                          <xs:documentation>
                            Timeout to acquire the lock which guards the state to be flushed to the cache store periodically.
                          </xs:documentation>
                        </xs:annotation>
                      </xs:attribute>
                      <xs:attribute name="modificationQueueSize" type="xs:int">
                        <xs:annotation>
                          <xs:documentation>
                            Sets the size of the modification queue for the async store. If updates are made at a rate that is faster than the underlying cache store can process this queue, then the async store behaves like a synchronous store for that period, blocking until the queue can accept more elements.
                          </xs:documentation>
                        </xs:annotation>
                      </xs:attribute>
                      <xs:attribute name="shutdownTimeout" type="xs:long">
                        <xs:annotation>
                          <xs:documentation>
                            Timeout to stop the cache store. When the store is stopped it's possible that some modifications still need to be applied; you likely want to set a very large timeout to make sure to not loose data
                          </xs:documentation>
                        </xs:annotation>
                      </xs:attribute>
                      <xs:attribute name="threadPoolSize" type="xs:int">
                        <xs:annotation>
                          <xs:documentation>
                            Size of the thread pool whose threads are responsible for applying the modifications.
                          </xs:documentation>
                        </xs:annotation>
                      </xs:attribute>
                    </xs:complexType>
                  </xs:element>
                  <xs:element name="singletonStore" minOccurs="0">
                    <xs:annotation>
                      <xs:documentation>
                        SingletonStore is a delegating cache store used for situations when only one instance in a cluster should interact with the underlying store. The coordinator of the cluster will be responsible for the underlying CacheStore. SingletonStore is a simply facade to a real CacheStore implementation. It always delegates reads to the real CacheStore.
                      </xs:documentation>
                    </xs:annotation>
                    <xs:complexType>
                      <xs:attribute name="pushStateTimeout" type="xs:long">
                        <xs:annotation>
                          <xs:documentation>
                            If pushStateWhenCoordinator is true, this property sets the maximum number of milliseconds that the process of pushing the in-memory state to the underlying cache loader should take.
                          </xs:documentation>
                        </xs:annotation>
                      </xs:attribute>
                      <xs:attribute name="pushStateWhenCoordinator" type="xs:boolean">
                        <xs:annotation>
                          <xs:documentation>
                            If true, when a node becomes the coordinator, it will transfer in-memory state to the underlying cache store. This can be very useful in situations where the coordinator crashes and there's a gap in time until the new coordinator is elected.
                          </xs:documentation>
                        </xs:annotation>
                      </xs:attribute>
                      <xs:attribute name="enabled" type="xs:boolean">
                        <xs:annotation>
                          <xs:documentation>
                            If true, the singleton store cache store is enabled.
                          </xs:documentation>
                        </xs:annotation>
                      </xs:attribute>
                    </xs:complexType>
                  </xs:element>
                  <xs:element name="properties" type="tns:properties" minOccurs="0">
                    <xs:annotation>
                      <xs:documentation>
                        Properties passed to the cache store or loader
                      </xs:documentation>
                    </xs:annotation>
                  </xs:element>
                </xs:all>
                <xs:attribute name="fetchPersistentState" type="xs:boolean">
                  <xs:annotation>
                    <xs:documentation>
                      If true, fetch persistent state when joining a cluster. If multiple cache stores are chained, only one of them can have this property enabled. Persistent state transfer with a shared cache store does not make sense, as the same persistent store that provides the data will just end up receiving it. Therefore, if a shared cache store is used, the cache will not allow a persistent state transfer even if a cache store has this property set to true. Finally, setting it to true only makes sense if in a clustered environment, and only 'replication' and 'invalidation' cluster modes are supported.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="ignoreModifications" type="xs:boolean">
                  <xs:annotation>
                    <xs:documentation>
                      If true, any operation that modifies the cache (put, remove, clear, store...etc) won't be applied to the cache store. This means that the cache store could become out of sync with the cache.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="purgeOnStartup" type="xs:boolean">
                  <xs:annotation>
                    <xs:documentation>
                      If true, purges this cache store when it starts up.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="purgeSynchronously" type="xs:boolean">
                  <xs:annotation>
                    <xs:documentation>
                      If true, CacheStore#purgeExpired() call will be done synchronously
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="purgerThreads" type="xs:int">
                  <xs:annotation>
                    <xs:documentation>
                      The number of threads to use when purging asynchronously.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="class" type="xs:string">
                  <xs:annotation>
                    <xs:documentation>
                      The cache loader to configure and use
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
              </xs:complexType>
            </xs:element>
          </xs:sequence>
          <xs:attribute name="passivation" type="xs:boolean">
            <xs:annotation>
              <xs:documentation>
                If true, data is only written to the cache store when it is evicted from memory, a phenomenon known as 'passivation'. Next time the data is requested, it will be 'activated' which means that data will be brought back to memory and removed from the persistent store. This gives you the ability to 'overflow' to disk, similar to swapping in an operating system. If false, the cache store contains a copy of the contents in memory, so writes to cache result in cache store writes. This essentially gives you a 'write-through' configuration.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="preload" type="xs:boolean">
            <xs:annotation>
              <xs:documentation>
                If true, when the cache starts, data stored in the cache store will be pre-loaded into memory. This is particularly useful when data in the cache store will be needed immediately after startup and you want to avoid cache operations being delayed as a result of loading this data lazily. Can be used to provide a 'warm-cache' on startup, however there is a performance penalty as startup time is affected by this process.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="shared" type="xs:boolean">
            <xs:annotation>
              <xs:documentation>
                This setting should be set to true when multiple cache instances share the same cache store (e.g., multiple nodes in a cluster using a JDBC-based CacheStore pointing to the same, shared database.) Setting this to true avoids multiple cache instances writing the same modification multiple times. If enabled, only the node where the modification originated will write to the cache store. If disabled, each individual cache reacts to a potential remote update by storing the data to the cache store. Note that this could be useful if each individual node has its own cache store - perhaps local on-disk.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <xs:element name="transaction" minOccurs="0">
        <xs:annotation>
          <xs:documentation>
            Defines transactional (JTA) characteristics of the cache.
          </xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:sequence>
            <xs:element name="recovery" minOccurs="0">
              <xs:annotation>
                <xs:documentation>
                  Defines recovery configuration for the cache.
                </xs:documentation>
              </xs:annotation>
              <xs:complexType>
                <xs:attribute name="enabled" type="xs:boolean" use="required">
                  <xs:annotation>
                    <xs:documentation>
                      Enable recovery for this cache.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="recoveryInfoCacheName" type="xs:string">
                  <xs:annotation>
                    <xs:documentation>
                      Sets the name of the cache where recovery related information is held. The cache's default name is specified by Configuration.RecoveryType.DEFAULT_RECOVERY_INFO_CACHE.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
              </xs:complexType>
            </xs:element>
          </xs:sequence>
          <xs:attribute name="cacheStopTimeout" type="xs:int">
            <xs:annotation>
              <xs:documentation>
                If there are any ongoing transactions when a cache is stopped, Infinispan waits for ongoing remote and local transactions to finish. The amount of time to wait for is defined by the cache stop timeout. It is recommended that this value does not exceed the transaction timeout because even if a new transaction was started just before the cache was stopped, this could only last as long as the transaction timeout allows it.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="eagerLockSingleNode" type="xs:boolean">
            <xs:annotation>
              <xs:documentation>
                 Only has effect for DIST mode and when useEagerLocking is set to true. When this is enabled, then only one node is locked in the cluster, disregarding numOwners config. On the opposite, if this is false, then on all cache.lock() calls numOwners RPCs are being performed. The node that gets locked is the main data owner, i.e. the node where data would reside if numOwners==1. If the node where the lock resides crashes, then the transaction is marked for rollback - data is in a consistent state, no fault tolerance. Starting with Infinispan 5.1 single node locking is used by default.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="syncCommitPhase" type="xs:boolean">
            <xs:annotation>
              <xs:documentation>
                If true, the cluster-wide commit phase in two-phase commit (2PC) transactions will be synchronous, so Infinispan will wait for responses from all nodes to which the commit was sent. Otherwise, the commit phase will be asynchronous. Keeping it as false improves performance of 2PC transactions, since any remote failures are trapped during the prepare phase anyway and appropriate rollbacks are issued.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="syncRollbackPhase" type="xs:boolean">
            <xs:annotation>
              <xs:documentation>
                If true, the cluster-wide rollback phase in two-phase commit (2PC) transactions will be synchronous, so Infinispan will wait for responses from all nodes to which the rollback was sent. Otherwise, the rollback phase will be asynchronous. Keeping it as false improves performance of 2PC transactions.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="transactionManagerLookupClass" type="xs:string">
            <xs:annotation>
              <xs:documentation>
                Configure Transaction manager lookup directly using an instance of TransactionManagerLookup. Calling this method marks the cache as transactional.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="useEagerLocking" type="xs:boolean">
            <xs:annotation>
              <xs:documentation>
                 Only has effect for DIST mode and when useEagerLocking is set to true. When this is enabled, then only one node is locked in the cluster, disregarding numOwners config. On the opposite, if this is false, then on all cache.lock() calls numOwners RPCs are being performed. The node that gets locked is the main data owner, i.e. the node where data would reside if numOwners==1. If the node where the lock resides crashes, then the transaction is marked for rollback - data is in a consistent state, no fault tolerance. Note: Starting with infinispan 5.1 eager locking is replaced with pessimistic locking and can be enforced by setting transaction's locking mode to PESSIMISTIC.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="useSynchronization" type="xs:boolean">
           <xs:annotation>
              <xs:documentation>
                 Configures whether the cache registers a synchronization with the transaction manager, or registers itself as an XA resource. It is often unnecessary to register as a full XA resource unless you intend to make use of recovery as well, and registering a synchronization is significantly more efficient.
              </xs:documentation>
           </xs:annotation>
          </xs:attribute>
          <xs:attribute name="lockingMode" type="tns:lockingMode">
            <xs:annotation>
              <xs:documentation>
                Configures whether the cache uses optimistic or pessimistic locking. If the cache is not transactional then the locking mode is ignored. See transactioMode.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="transactionMode" type="tns:transactionMode">
            <xs:annotation>
              <xs:documentation>
                Configures whether the cache is transactional or not.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="autoCommit" type="xs:boolean">
            <xs:annotation>
              <xs:documentation>
                If the cache is transactional and transactionAutoCommit is enabled then for single operation transactions the user doesn't need to manually start a transaction, but a transactions is injected by the system. Defaults to true.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="use1PcForAutoCommitTransactions" type="xs:boolean">
            <xs:annotation>
              <xs:documentation>
                Before Infinispan 5.1 you could access the cache both transactionally and non-transactionally. Naturally the non-transactional access is faster and offers less consistency guarantees. From Infinispan 5.1 onwards, mixed access is no longer supported, so if you wanna speed up transactional caches and you're ready to trade some consistency guarantees, you can enable use1PcForAutoCommitTransactions. What this configuration option does is force an induced transaction, that has been started by Infinispan as a result of enabling autoCommit, to commit in a single phase. So only 1 RPC instead of 2RPCs as in the case of a full 2 Phase Commit (2PC).
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <xs:element name="customInterceptors" minOccurs="0">
        <xs:annotation>
          <xs:documentation>
            Configures custom interceptors to be added to the cache.
          </xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:sequence>
            <xs:element name="interceptor" minOccurs="0" maxOccurs="unbounded">
              <xs:complexType>
                <xs:sequence>
                  <xs:element name="properties" type="tns:properties" minOccurs="0"/>
                </xs:sequence>
                <xs:attribute name="after" type="xs:string">
                   <xs:annotation><xs:documentation>Dictates that the custom interceptor appears immediately after the specified interceptor. If the specified interceptor is not found in the interceptor chain, a ConfigurationException will be thrown when the cache starts.</xs:documentation></xs:annotation>
                </xs:attribute>
                <xs:attribute name="before" type="xs:string">
                   <xs:annotation><xs:documentation>Dictates that the custom interceptor appears immediately before the specified interceptor. If the specified interceptor is not found in the interceptor chain, a ConfigurationException will be thrown when the cache starts.</xs:documentation></xs:annotation>
                </xs:attribute>
                <xs:attribute name="class" type="xs:string">
                   <xs:annotation><xs:documentation>A fully qualified class name of the new custom interceptor to add to the configuration.</xs:documentation></xs:annotation>
                </xs:attribute>
                <xs:attribute name="index" type="xs:int">
                   <xs:annotation><xs:documentation>Specifies a position in the interceptor chain to place the new interceptor. The index starts at 0 and goes up to the number of interceptors in a given configuration. A ConfigurationException is thrown if the index is less than 0 or greater than the maximum number of interceptors in the chain.</xs:documentation></xs:annotation>
                </xs:attribute>
                <xs:attribute name="position" type="xs:string">
                   <xs:annotation><xs:documentation>Specifies a position where to place the new interceptor. Allowed values are FIRST, LAST, and OTHER_THAN_FIRST_OR_LAST</xs:documentation></xs:annotation>
                </xs:attribute>
              </xs:complexType>
            </xs:element>
          </xs:sequence>
        </xs:complexType>
      </xs:element>
      <xs:element name="dataContainer" minOccurs="0">
        <xs:annotation>
          <xs:documentation>
            Controls the data container for the cache.
          </xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:sequence>
            <xs:element name="properties" type="tns:properties" minOccurs="0">
              <xs:annotation>
                <xs:documentation>Properties passed to the data container</xs:documentation>
              </xs:annotation>
            </xs:element>
          </xs:sequence>
          <xs:attribute name="class" type="xs:string">
            <xs:annotation>
              <xs:documentation>
                Fully qualified class name of the data container to use
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <xs:element name="eviction" minOccurs="0">
        <xs:annotation>
          <xs:documentation>
            Controls the eviction settings for the cache.
          </xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="maxEntries" type="xs:int">
            <xs:annotation>
              <xs:documentation>
                Maximum number of entries in a cache instance. Cache size is guaranteed not to exceed upper limit specified by max entries. However, due to the nature of eviction it is unlikely to ever be exactly maximum number of entries specified here.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="strategy" type="tns:evictionStrategy">
            <xs:annotation>
              <xs:documentation>
                Eviction strategy. Available options are 'UNORDERED', 'LRU', 'LIRS' and 'NONE' (to disable eviction).
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="threadPolicy" type="tns:evictionThreadPolicy">
            <xs:annotation>
              <xs:documentation>
                Threading policy for eviction.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="wakeUpInterval" type="xs:long">
            <xs:annotation>
              <xs:documentation>
                Deprecated, set on expiration instead. Interval (in milliseconds) between subsequent runs to purge expired entries from memory and any cache stores. If you wish to disable the periodic eviction process altogether, set wakeupInterval to -1.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <xs:element name="expiration" minOccurs="0">
        <xs:annotation>
          <xs:documentation>
            Controls the default expiration settings for entries in the cache.
          </xs:documentation>
        </xs:annotation>
        <xs:complexType>
           <xs:attribute name="wakeUpInterval" type="xs:long">
            <xs:annotation>
              <xs:documentation>
                Interval (in milliseconds) between subsequent runs to purge expired entries from memory and any cache stores. If you wish to disable the periodic eviction process altogether, set wakeupInterval to -1.
              </xs:documentation>
            </xs:annotation>
           </xs:attribute>
           <xs:attribute name="lifespan" type="xs:long">
            <xs:annotation>
              <xs:documentation>
                Maximum lifespan of a cache entry, after which the entry is expired cluster-wide, in milliseconds. -1 means the entries never expire. Note that this can be overridden on a per-entry basis by using the Cache API.
              </xs:documentation>
            </xs:annotation>
           </xs:attribute>
           <xs:attribute name="maxIdle" type="xs:long">
            <xs:annotation>
              <xs:documentation>
                Maximum idle time a cache entry will be maintained in the cache, in milliseconds. If the idle time is exceeded, the entry will be expired cluster-wide. -1 means the entries never expire. Note that this can be overridden on a per-entry basis by using the Cache API.
              </xs:documentation>
            </xs:annotation>
           </xs:attribute>
           <xs:attribute name="reaperEnabled" type="xs:boolean">
            <xs:annotation>
              <xs:documentation>
                Determines whether the background reaper thread is enabled to test entries for expiration. Regardless of whether a reaper is used, entries are tested for expiration lazily when they are touched.
              </xs:documentation>
            </xs:annotation>
           </xs:attribute>
        </xs:complexType>
      </xs:element>
      <xs:element name="unsafe" minOccurs="0">
        <xs:annotation>
          <xs:documentation>
            Controls certain tuning parameters that may break some of Infinispan's public API contracts in exchange for better performance in some cases. Use with care, only after thoroughly reading and understanding the documentation about a specific feature.
          </xs:documentation>
        </xs:annotation>
        <xs:complexType>
           <xs:attribute name="unreliableReturnValues" type="xs:boolean">
            <xs:annotation>
              <xs:documentation>
                Specifies whether Infinispan is allowed to disregard the Map contract when providing return values for org.infinispan.Cache#put(Object, Object) and org.infinispan.Cache#remove(Object) methods.
              </xs:documentation>
            </xs:annotation>
           </xs:attribute>
        </xs:complexType>
      </xs:element>
      <xs:element name="clustering" minOccurs="0">
        <xs:annotation>
          <xs:documentation>
            Defines clustered characteristics of the cache.
          </xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:all>
            <xs:element name="sync" minOccurs="0">
              <xs:annotation>
                <xs:documentation>
                  If configured all communications are synchronous, in that whenever a thread sends a message sent over the wire, it blocks until it receives an acknowledgment from the recipient. Sync configuration is mutually exclusive with async configuration. 
                </xs:documentation>
              </xs:annotation>
              <xs:complexType>
                <xs:attribute name="replTimeout" type="xs:long">
                  <xs:annotation>
                    <xs:documentation>
                      This is the timeout used to wait for an acknowledgment when making a remote call, after which the call is aborted and an exception is thrown.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
              </xs:complexType>
            </xs:element>
            <xs:element name="stateRetrieval" minOccurs="0">
              <xs:annotation>
                <xs:documentation>
                  Configures how state is retrieved when a new cache joins the cluster. Used with invalidation and replication clustered modes.
                </xs:documentation>
              </xs:annotation>
              <xs:complexType>
                <xs:attribute name="alwaysProvideInMemoryState" type="xs:boolean">
                  <xs:annotation>
                    <xs:documentation>
                      If true, this will allow the cache to provide in-memory state to a neighbor, even if the cache is not configured to fetch state from its neighbors (fetchInMemoryState is false)
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="fetchInMemoryState" type="xs:boolean">
                  <xs:annotation>
                    <xs:documentation>
                      If true, this will cause the cache to ask neighboring caches for state when it starts up, so the cache starts 'warm', although it will impact startup time.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="initialRetryWaitTime" type="xs:long">
                  <xs:annotation>
                    <xs:documentation>
                      Initial wait time when backing off before retrying state transfer retrieval
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="logFlushTimeout" type="xs:long">
                  <xs:annotation>
                    <xs:documentation>
                      This is the maximum amount of time to run a cluster-wide flush, to allow for syncing of transaction logs.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="maxNonProgressingLogWrites" type="xs:int">
                  <xs:annotation>
                    <xs:documentation>
                      This is the maximum number of non-progressing transaction log writes after which a brute-force flush approach is resorted to, to synchronize transaction logs.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="numRetries" type="xs:int">
                  <xs:annotation>
                    <xs:documentation>
                      Number of state retrieval retries before giving up and aborting startup.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="retryWaitTimeIncreaseFactor" type="xs:int">
                  <xs:annotation>
                    <xs:documentation>
                      Wait time increase factor over successive state retrieval backoffs
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="timeout" type="xs:long">
                  <xs:annotation>
                    <xs:documentation>
                      This is the maximum amount of time - in milliseconds - to wait for state from neighboring caches, before throwing an exception and aborting startup.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
              </xs:complexType>
            </xs:element>
            <xs:element name="stateTransfer" minOccurs="0">
              <xs:annotation>
                <xs:documentation>
                  Configures how state is transferred when a cache joins or leaves the cluster. Used in distributed and replication clustered modes.
                </xs:documentation>
              </xs:annotation>
              <xs:complexType>
                <xs:attribute name="chunkSize" type="xs:int">
                  <xs:annotation>
                    <xs:documentation>
                       If &gt; 0, the state will be transferred in batches of {@code chunkSize} cache entries. If &lt;= 0, the state will be transferred in all at once. Not recommended.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="fetchInMemoryState" type="xs:boolean">
                  <xs:annotation>
                    <xs:documentation>
                      If true, this will cause the cache to ask neighboring caches for state when it starts up, so the cache starts 'warm', although it will impact startup time.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="timeout" type="xs:long">
                  <xs:annotation>
                    <xs:documentation>
                      This is the maximum amount of time - in milliseconds - to wait for state from neighboring caches, before throwing an exception and aborting startup.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
              </xs:complexType>
            </xs:element>
            <xs:element name="l1" minOccurs="0">
              <xs:annotation>
                <xs:documentation>
                  Configures the L1 cache behavior in 'distributed' caches instances. In any other cache modes, this element is ignored.
                </xs:documentation>
              </xs:annotation>
              <xs:complexType>
                <xs:attribute name="enabled" type="xs:boolean">
                  <xs:annotation>
                    <xs:documentation>
                      Enable the L1 cache.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="invalidationThreshold" type="xs:int">
                  <xs:annotation>
                    <xs:documentation>
                      Determines whether a multicast or a web of unicasts are used when performing L1 invalidations. By default multicast will be used. If the threshold is set to -1, then unicasts will always be used. If the threshold is set to  0, then multicast will be always be used.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="lifespan" type="xs:long">
                  <xs:annotation>
                    <xs:documentation>
                      Maximum lifespan of an entry placed in the L1 cache.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="cleanupTaskFrequency" type="xs:long">
                   <xs:annotation>
                      <xs:documentation>
                         Controls how often a cleanup task to prune L1 tracking data is run.
                      </xs:documentation>
                   </xs:annotation>
                </xs:attribute>
                <xs:attribute name="onRehash" type="xs:boolean">
                  <xs:annotation>
                    <xs:documentation>
                       If enabled, entries removed due to a rehash will be moved to L1 rather than being removed altogether.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
              </xs:complexType>
            </xs:element>
            <xs:element name="async" minOccurs="0">
              <xs:annotation>
                <xs:documentation>
                  If configured all communications are asynchronous, in that whenever a thread sends a message sent over the wire, it does not wait for an acknowledgment before returning. Asynchronous configuration is mutually exclusive with synchronous configuration.
                </xs:documentation>
              </xs:annotation>
              <xs:complexType>
                <xs:annotation>
                  <xs:documentation>
                    If configured all communications are asynchronous, in that whenever a thread sends a message sent over the wire, it does not wait for an acknowledgment before returning. &lt;async&gt; is mutually exclusive with the &lt;sync&gt;.
                  </xs:documentation>
                </xs:annotation>
                <xs:attribute name="asyncMarshalling" type="xs:boolean">
                  <xs:annotation>
                    <xs:documentation>
                      If true, asynchronous marshalling is enabled which means that caller can return even quicker, but it can suffer from reordering of operations. You can find more information at https://docs.jboss.org/author/display/ISPN/Asynchronous+Options
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="replQueueClass" type="xs:string">
                  <xs:annotation>
                    <xs:documentation>
                      The replication queue in use, by default ReplicationQueueImpl.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="replQueueInterval" type="xs:long">
                  <xs:annotation>
                    <xs:documentation>
                      If useReplQueue is set to true, this attribute controls how often the asynchronous thread used to flush the replication queue runs.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="replQueueMaxElements" type="xs:int">
                  <xs:annotation>
                    <xs:documentation>
                      If useReplQueue is set to true, this attribute can be used to trigger flushing of the queue when it reaches a specific threshold.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="useReplQueue" type="xs:boolean">
                  <xs:annotation>
                    <xs:documentation>
                      If true, forces all async communications to be queued up and sent out periodically as a batch.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
              </xs:complexType>
            </xs:element>
            <xs:element name="hash" minOccurs="0">
              <xs:annotation>
                <xs:documentation>
                  Allows fine-tuning of rehashing characteristics. Must only used with 'distributed' cache mode.
                </xs:documentation>
              </xs:annotation>
              <xs:complexType>
                <xs:sequence>
                  <xs:element name="groups" minOccurs="0">
                    <xs:complexType>
                      <xs:sequence>
                        <xs:element name="grouper" minOccurs="0" maxOccurs="unbounded">
                          <xs:complexType>
                            <xs:attribute name="class" type="xs:string"/>
                          </xs:complexType>
                        </xs:element>
                      </xs:sequence>
                      <xs:attribute name="enabled" type="xs:boolean"/>
                    </xs:complexType>
                  </xs:element>
                </xs:sequence>
                <xs:attribute name="class" type="xs:string">
                  <xs:annotation>
                    <xs:documentation>
                      The consistent hash in use.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="hashFunctionClass" type="xs:string">
                  <xs:annotation>
                    <xs:documentation>
                      The hash function in use. Used as a bit spreader and a general hash code generator. Typically one of the the many default org.infinispan.distribution.ch.ConsistentHash implementations shipped.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="numOwners" type="xs:int">
                  <xs:annotation>
                    <xs:documentation>
                      Number of cluster-wide replicas for each cache entry.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="numVirtualNodes" type="xs:int">
                  <xs:annotation>
                    <xs:documentation>
                      Controls the number of virtual nodes per "real" node. You can read more about virtual nodes at TODO. If numVirtualNodes is 1, then virtual nodes are disabled. A default of 1 is used.
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="rehashEnabled" type="xs:boolean">
                  <xs:annotation>
                    <xs:documentation>
                      If false, no rebalancing or rehashing will take place when a new node joins the cluster or a node leaves
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="rehashRpcTimeout" type="xs:long">
                  <xs:annotation>
                    <xs:documentation>
                      Rehashing timeout
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
                <xs:attribute name="rehashWait" type="xs:long">
                  <xs:annotation>
                    <xs:documentation>
                      TODO
                    </xs:documentation>
                  </xs:annotation>
                </xs:attribute>
              </xs:complexType>
            </xs:element>
          </xs:all>
          <xs:attribute name="mode" type="xs:string">
            <xs:annotation>
              <xs:documentation>
                Cache mode. For distribution, set mode to either 'dist'. For replication, use 'repl'. Finally, for invalidation 'inv'. If the cache mode is set to 'local', the cache in question will not support clustering even if its cache manager does.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <xs:element name="jmxStatistics" minOccurs="0">
        <xs:annotation>
          <xs:documentation>
            Determines whether statistics are gather and reported.
          </xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="enabled" type="xs:boolean">
            <xs:annotation>
              <xs:documentation>
                Enable or disable statistics gathering and reporting
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <xs:element name="storeAsBinary" minOccurs="0">
        <xs:annotation>
          <xs:documentation>
            Controls whether when stored in memory, keys and values are stored as references to their original objects, or in a serialized, binary format.  There are benefits to both approaches, but often if used in a clustered mode, storing objects as binary means that the cost of serialization happens early on, and can be amortized.  Further, deserialization costs are incurred lazily which improves throughput. It is possible to control this on a fine-grained basis: you can choose to just store keys or values as binary, or both.
          </xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="enabled" type="xs:boolean">
            <xs:annotation>
              <xs:documentation>
                Enables storing both keys and values as binary.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="storeKeysAsBinary" type="xs:boolean">
            <xs:annotation>
              <xs:documentation>
                Specify whether keys are stored as binary or not.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="storeValuesAsBinary" type="xs:boolean">
            <xs:annotation>
              <xs:documentation>
                Specify whether values are stored as binary or not.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <xs:element name="lazyDeserialization" minOccurs="0">
        <xs:annotation>
          <xs:documentation>
            Deprecated configuration element. Use storeAsBinary instead.
          </xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="enabled" type="xs:boolean"/>
        </xs:complexType>
      </xs:element>
      <xs:element name="invocationBatching" minOccurs="0">
        <xs:complexType>
          <xs:attribute name="enabled" type="xs:boolean"/>
        </xs:complexType>
      </xs:element>
      <xs:element name="deadlockDetection" minOccurs="0">
        <xs:annotation>
          <xs:documentation>
            Configures deadlock detection.
          </xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:attribute name="enabled" type="xs:boolean">
            <xs:annotation>
              <xs:documentation>
                Enable or disable deadlock detection
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="spinDuration" type="xs:long">
            <xs:annotation>
              <xs:documentation>
                Time period that determines how often is lock acquisition attempted within maximum time allowed to acquire a particular lock
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
      <xs:element name="indexing" minOccurs="0">
        <xs:annotation>
          <xs:documentation>
            Configures indexing of entries in the cache for searching.
          </xs:documentation>
        </xs:annotation>
        <xs:complexType>
          <xs:sequence>
            <xs:element name="properties" type="tns:properties" minOccurs="0">
              <xs:annotation>
                <xs:documentation>
                  The Query engine relies on properties for configuration. These properties are passed directly to the embedded Hibernate Search engine, so for the complete and up to date documentation about available properties refer to the Hibernate Search reference of the version you're using with Infinispan Query.
                </xs:documentation>
              </xs:annotation>
            </xs:element>
          </xs:sequence>
          <xs:attribute name="enabled" type="xs:boolean">
            <xs:annotation>
              <xs:documentation>
                Enable or disable indexing
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="indexLocalOnly" type="xs:boolean">
            <xs:annotation>
              <xs:documentation>
                If true, only index changes made locally, ignoring remote changes. This is useful if indexes are shared across a cluster to prevent redundant indexing of updates.
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
    </xs:all>
    <xs:attribute name="name" type="xs:string"/>
  </xs:complexType>

  <xs:complexType name="executorFactory">
    <xs:sequence>
      <xs:element name="properties" type="tns:properties" minOccurs="0">
        <xs:annotation>
          <xs:documentation>
            Add key/value property pair to this factory configuration. Example properties include "maxThreads" which sets the maximum number of threads for this executor (default values can be found at https://docs.jboss.org/author/display/ISPN/Default+Values+For+Property+Based+Attribute). Another example is "threadNamePrefix" which sets the thread name prefix for threads created by this executor (default values can be found at https://docs.jboss.org/author/display/ISPN/Default+Values+For+Property+Based+Attributes).
          </xs:documentation>
        </xs:annotation>
      </xs:element>
    </xs:sequence>
    <xs:attribute name="factory" type="xs:string">
      <xs:annotation>
        <xs:documentation>
          Fully qualified class name of the ExecutorFactory to use.  Must implement org.infinispan.executors.ExecutorFactory
        </xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>

  <xs:complexType name="properties">
    
    <xs:sequence>
      <xs:element name="property" minOccurs="0" maxOccurs="unbounded">
        <xs:complexType>
          <xs:attribute name="name" type="xs:string">
            <xs:annotation>
              <xs:documentation>
                The property name or key
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
          <xs:attribute name="value" type="xs:string">
            <xs:annotation>
              <xs:documentation>
                The property value
              </xs:documentation>
            </xs:annotation>
          </xs:attribute>
        </xs:complexType>
      </xs:element>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="scheduledExecutorFactory">
    <xs:sequence>
       <xs:element name="properties" type="tns:properties" minOccurs="0">
         <xs:annotation>
            <xs:documentation>
               Add key/value property pair to this factory configuration. Example properties include "maxThreads" which sets the maximum number of threads for this executor (default values can be found at https://docs.jboss.org/author/display/ISPN/Default+Values+For+Property+Based+Attribute). Another example is "threadNamePrefix" which sets the thread name prefix for threads created by this executor (default values can be found at https://docs.jboss.org/author/display/ISPN/Default+Values+For+Property+Based+Attributes).
            </xs:documentation>
         </xs:annotation>
       </xs:element>
     </xs:sequence>
     <xs:attribute name="factory" type="xs:string">
      <xs:annotation>
         <xs:documentation>
            Fully qualified class name of the ScheduledExecutorFactory to use.  Must implement org.infinispan.executors.ScheduledExecutorFactory
         </xs:documentation>
      </xs:annotation>
     </xs:attribute>
  </xs:complexType>

  <xs:simpleType name="shutdownHookBehavior">
    <xs:restriction base="xs:string">
      <xs:enumeration value="DEFAULT"/>
      <xs:enumeration value="REGISTER"/>
      <xs:enumeration value="DONT_REGISTER"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="isolationLevel">
    <xs:restriction base="xs:string">
      <xs:enumeration value="NONE"/>
      <xs:enumeration value="SERIALIZABLE"/>
      <xs:enumeration value="REPEATABLE_READ"/>
      <xs:enumeration value="READ_COMMITTED"/>
      <xs:enumeration value="READ_UNCOMMITTED"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="evictionStrategy">
    <xs:restriction base="xs:string">
      <xs:enumeration value="NONE"/>
      <xs:enumeration value="UNORDERED"/>
      <xs:enumeration value="FIFO"/>
      <xs:enumeration value="LRU"/>
      <xs:enumeration value="LRU_OLD"/>
      <xs:enumeration value="LIRS"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="evictionThreadPolicy">
    <xs:restriction base="xs:string">
      <xs:enumeration value="PIGGYBACK"/>
      <xs:enumeration value="DEFAULT"/>
    </xs:restriction>
  </xs:simpleType>
  
  <xs:simpleType name="lockingMode">
    <xs:annotation>
      <xs:documentation>
        Defines the locking modes that are available for transactional caches: optimistic or pessimistic - see http://community.jboss.org/wiki/OptimisticLockingInInfinispan for more.
      </xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="OPTIMISTIC" />
      <xs:enumeration value="PESSIMISTIC" />
    </xs:restriction>
  </xs:simpleType>
  
  <xs:simpleType name="transactionMode">
    <xs:annotation>
      <xs:documentation>
        Enumeration containing the available transaction modes for a cache.
      </xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
      <xs:enumeration value="NON_TRANSACTIONAL" />
      <xs:enumeration value="TRANSACTIONAL" />
    </xs:restriction>
  </xs:simpleType>
</xs:schema>

