[ https://issues.jboss.org/browse/ISPN-4697?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-4697: ---------------------------------- Description: For a similar reason as explained in ISPN-4650, the method {{org.infinispan.query.backend.QueryInterceptor.processPutKeyValueCommand(PutKeyValueCommand, InvocationContext, Object, TransactionContext)}} is likely to invoke a {{removeFromIndexes}} first and then an {{updateIndexes}}. When using transactions, the {{transactionContext}} will enqueue both operations for execution in the same call to the backend, but when no transaction is in progress, this will generate two sequential and independent calls to the backend. When the backend happens to be the {{InfinispanIndexManager}}, this implies we're generating two sequential synchronous RPCs rather than bacthing the two operations in a single Update statement: the first call is completely redundant in most cases, and can be incorporated in the second call for all remaining edge cases. was: For a similar reason as explained in ISPN-4650, the method {{org.infinispan.query.backend.QueryInterceptor.processPutKeyValueCommand(PutKeyValueCommand, InvocationContext, Object, TransactionContext)}} is likely to invoke a {{removeFromIndexes}} first and then an {{updateIndexes}}. When using transactions, the {{transactionContext}} will not be null and the backend will enqueue both operations for execution in the same call to the backend, but when there is no such context, this will generate two sequential and independent calls to the backend. When the backend happens to be the {{InfinispanIndexManager}}, this implies we're generating two sequential synchronous RPCs rather than bacthing the two operations in a single Update statement: the first call is completely redundant in most cases, and can be incorporated in the second call for all remaining edge cases. -- This message was sent by Atlassian JIRA (v6.3.1#6329)