2017-07-25 6 views
2

Je le projet de migration Infinispan 9.1.0.Final de 8.2.4.Final et obtenu exception suivante:Infinispan 9.1: Mode cache non pris en charge async 'REPL_ASYNC' pour les caches transactionnels

org.infinispan. commons.CacheConfigurationException: ISPN000441: Mode cache non pris en charge async 'REPL_ASYNC' pour les caches transactionnels

Code connexes:

new ConfigurationBuilder() 
      .jmxStatistics() 
      .enabled(false) 
      .available(false) 
      .clustering() 
      .cacheMode(CacheMode.REPL_ASYNC) 
      .stateTransfer().awaitInitialTransfer(false) 
      .transaction() 
      .transactionManagerLookup(new DummyTransactionManagerLookup()) 
      .transactionMode(TransactionMode.TRANSACTIONAL) 
      .lockingMode(LockingMode.PESSIMISTIC) 
      .recovery() 
      .enabled(false) 
      .invocationBatching() 
      .enable(false) 
      .indexing() 
      .index(Index.ALL) 
      .addProperty("default.indexmanager", "near-real-time") 
      .addProperty("default.directory_provider", "ram") 
      .addProperty("default.worker.execution", "sync") 
      .addProperty("default.exclusive_index_use", "true") 
      .addProperty("default.reader.strategy", "shared") 
      .build(); 

Et peigne problème ici, mais dans la version 8.2.4.Final cela fonctionne bien.

.cacheMode(CacheMode.REPL_ASYNC) 
.transactionMode(TransactionMode.TRANSACTIONAL) // Maybe is there another way to lock put operations? 

Comment dois-je reconfigurer le cache pour sauvegarder ses caractéristiques?

Répondre

2

Le mode asynchrone des caches transactionnels n'était pas sûr car il n'attendait pas que la transaction soit validée dans chaque nœud du cluster avant de rapporter au TransactionManager. Cela peut rendre vos données incohérentes si vous êtes malchanceux.

Pour éviter tout problème, il a été supprimé. Veuillez mettre à jour votre configuration pour utiliser REPL_SYNC à la place.

En outre, le DummyTransactionManagerLookup a été déprécié et il doit être remplacé par EmbeddedTransactionManagerLookup.

Il existe d'autres modifications liées aux transactions entre 8.x et 9.x. S'il vous plaît jeter un oeil au guide de mise à niveau (http://infinispan.org/docs/stable/upgrading/upgrading.html#upgrading_from_8_x_to_9_0) pour plus de détails.

+0

Cela fonctionne solution, mais l'application met très souvent des éléments à une partie du cache distribué, et maintenant, avec REPL_ASYNC, le noeud mis à jour informe d'autres sur cet événement. Et ils mettent à jour leurs propres instances de cache automatiquement. Avec REPL_SYNC, le noeud demandé doit demander à l'autre de donner un nouvel élément, donc la latence de put sera automatiquement augmentée. Que pouvez-vous suggérer? –

+0

Je ne sais pas si je comprends votre cas d'utilisation, mais transigez-vous vraiment? Les caches non-transactionnels peuvent toujours utiliser le mode asynchrone. Si vous n'avez pas besoin de la valeur précédente de la put (k, v), vous pouvez définir IGNORE_RETURN_VALUES comme: AdvanceCache.withFlags (IGNORE_RETURN_VALUES) .put (k, v), mais il faudra encore aller à distance acquérir le verrou (si le noeud n'est pas le propriétaire du verrou). – pruivo