org.infinispan.configuration.cache Documentation Differences

This file contains all the changes in documentation in the package org.infinispan.configuration.cache as colored differences. Deletions are shown like this, and additions are shown like this.

If no deletions or additions are shown in an entry, the HTML tags will be what has changed. The new HTML tags are shown in the differences. If no documentation existed, and then some was added in a later version, this change is noted in the appropriate class pages of differences, but the change is not shown on this page. Only changes in existing text are shown here. Similarly, documentation which was inherited from another class or interface is not shown here.

Note that an HTML error in the new documentation may cause the display of other documentation changes to be presented incorrectly. For instance, failure to close a <code> tag will cause all subsequent paragraphs to be displayed differently.

If > 0, theThe state will be transferred in batches of {@code chunkSize} cache entries. If <=chunkSize is equal 0to Integer.MAX_VALUE, the state will be transferred in all at once. Not recommended.

If > 0, theThe state will be transferred in batches of {@code chunkSize} cache entries. If <=chunkSize is equal 0to Integer.MAX_VALUE, the state will be transferred in all at once. Not recommended.

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 duringbut it can lead to inconsistencies when the prepare primary phaseowner releases the lock anyway and appropriate rollbacks are issuedbefore the backup commits the change.

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 duringbut it can lead to inconsistencies when the prepare primary phaseowner releases the lock before the backup commits the change. @deprecated The anyway and appropriate rollbacks aresyncRollbackPhase setting can no longer issuedbe modified at runtime. It must be the same on all nodes.

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,@deprecated the rollback phase will beThe syncRollbackPhase setting can no asynchronous.longer Keeping it asbe modified at falseruntime. improves performance of 2PCIt must be the transactions. same @paramon b all @returnnodes.

The duration (millis) in which to keep information about the completion of a transaction. Defaults to 300060000.

Configures whether the cache uses optimistic or pessimistic locking. If the cache is not transactional then the locking mode is ignored. @see org.infinispan.configconfiguration.Configurationcache.TransactionConfiguration#isTransactionalCachetransactionMode()

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, sincebut any remote failures are trappedit during the prepare phase anyway and appropriate rollbacks arecan lead to inconsistencies when a backup owner only issued. commits the This configuration property may be adjusted attransaction after the primary owner released the runtimelock.

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 2PCcan lead to inconsistencies transactions. when a This configuration property maytransaction is rolled back bebecause of a commit timeout, as adjusteda atbackup owner could commit the transaction after the primary released the runtimelock.