Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Ce contenu n'est pas disponible dans la langue sélectionnée.

20.2. Write-Behind Caching

In Red Hat JBoss Data Grid's Write-Behind (Asynchronous) mode, cache updates are asynchronously written to the cache store. Asynchronous updates ensure that cache store updates are carried out by a thread different from the client thread interacting with the cache.
One of the foremost advantages of the Write-Behind mode is that the cache operation performance is not affected by the underlying store update. However, because of the asynchronous updates, for a brief period the cache store contains stale data compared to the cache.
Report a bug

20.2.1. About Unscheduled Write-Behind Strategy
Copier lien

In the Unscheduled Write-Behind Strategy mode, Red Hat JBoss Enterprise Data Grid attempts to store changes as quickly as possible by applying pending changes in parallel. This results in multiple threads waiting for modifications to conclude. Once these modifications are concluded, the threads become available and the modifications are applied to the underlying cache store.
This strategy is ideal for cache stores with low latency and low operational costs. An example of this is a local unshared file based cache store in which the cache store is local to the cache itself. Using this strategy the period of time where an inconsistency exists between the contents of the cache and the contents of the cache store is reduced to the shortest possible interval.
Report a bug
To set the write-behind strategy in Red Hat JBoss Data Grid's Remote Client-Server mode, add the write-behind element to the target cache store configuration as follows:

Procedure 20.2. The write-behind Element

The write-behind element uses the following configuration parameters:

  1. The modification-queue-size Parameter

    The modification-queue-size parameter sets the modification queue size for the asynchronous store. If updates occur faster than the cache store can process the queue, the asynchronous store behaves like a synchronous store. The store behavior remains synchronous and blocks elements until the queue is able to accept them, after which the store behavior becomes asynchronous again. 
    <file-store passivation="false" 
            path="${PATH}" 
            purge="true" 
            shared="false">
    <write-behind modification-queue-size="1024" />

  2. The shutdown-timeout Parameter

    The shutdown-timeout parameter specifies the time in milliseconds after which the cache store is shut down. When the store is stopped some modifications may still need to be applied. Setting a large timeout value will reduce the chance of data loss. The default value for this parameter is 25000. 
    <file-store passivation="false" 
            path="${PATH}" 
            purge="true" 
            shared="false">
    <write-behind modification-queue-size="1024" 
                  shutdown-timeout="25000" />

  3. The flush-lock-timeout Parameter

    The flush-lock-timeout parameter specifies the time (in milliseconds) to acquire the lock that guards the state to be periodically flushed. The default value for this parameter is 15000. 
    <file-store passivation="false" 
            path="${PATH}" 
            purge="true" 
            shared="false">
    <write-behind modification-queue-size="1024" 
                  shutdown-timeout="25000"  
                  flush-lock-timeout="15000" />

  4. The thread-pool-size Parameter

    The thread-pool-size parameter specifies the size of the thread pool. The threads in this thread pool apply modifications to the cache store. The default value for this parameter is 5. 
    <file-store passivation="false" 
            path="${PATH}" 
            purge="true" 
            shared="false">
    <write-behind modification-queue-size="1024" 
                  shutdown-timeout="25000"  
                  flush-lock-timeout="15000" 
                  thread-pool-size="5" />
</file-store>
Report a bug
To enable the write-behind strategy of the cache entries to a store, add the async element to the store configuration as follows:

Procedure 20.3. The async Element

The async element uses the following configuration parameters:
  1. The modificationQueueSize parameter sets the modification queue size for the asynchronous store. If updates occur faster than the cache store can process the queue, the asynchronous store behaves like a synchronous store. The store behavior remains synchronous and blocks elements until the queue is able to accept them, after which the store behavior becomes asynchronous again. 
    <persistence>
    <fileStore location="${LOCATION}">
        <async enabled="true" 
                    modificationQueueSize="1024" />
  2. The shutdownTimeout parameter specifies the time in milliseconds after which the cache store is shut down. This provides time for the asynchronous writer to flush data to the store when a cache is shut down. The default value for this parameter is 25000. 
    <persistence>
    <fileStore location="${LOCATION}">
        <async enabled="true" 
                    modificationQueueSize="1024" 
                    shutdownTimeout="25000" />
  3. The flushLockTimeout parameter specifies the time (in milliseconds) to acquire the lock that guards the state to be periodically flushed. The default value for this parameter is 15000. 
    <persistence>
    <fileStore location="${LOCATION}">
        <async enabled="true" 
                    modificationQueueSize="1024" 
                    shutdownTimeout="25000" 
                    flushLockTimeout="15000" />
  4. The threadPoolSize parameter specifies the number of threads that concurrently apply modifications to the store. The default value for this parameter is 5. 
    <persistence>
    <fileStore location="${LOCATION}">
        <async enabled="true" 
                    modificationQueueSize="1024" 
                    shutdownTimeout="25000" 
                    flushLockTimeout="15000" 
                    threadPoolSize="5"/>
    </fileStore>
</persistence>
Report a bug
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2026 Red HatRetour au début