[infinispan-issues] [JBoss JIRA] Commented: (ISPN-927) Cache inserts inside a transaction are not propagated across the cluster in distributed mode

[ https://issues.jboss.org/browse/ISPN-927?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño commented on ISPN-927: --------------------------------------- I found the cause for this. The problem arises when the thread doing the modifications, put/remove...etc is different to the thread doing the commit. The context of which threads have been modified is maintained as a thread local, so when the thread doing commit comes along, the thread local used is different to check the affected keys, and considers that no modifications were made. Let me show you an example: {code}2011-02-15 10:23:03,019 20138 TRACE [org.infinispan.interceptors.CallInterceptor] (pool-4-thread-1:) Executing command: PutKeyValueCommand{key=key2, value=bob85, putIfAbsent=false, lifespanMillis=-1, maxIdleTimeMillis=-1}. 2011-02-15 10:23:03,019 20138 TRACE [org.infinispan.interceptors.DistributionInterceptor] (pool-4-thread-1:) Adding keys=[key2] to context LocalTxInvocationContext{flags=null}@7ced65e0 {code} In the above log you see how a put is executed for key2=bob85, now here comes the prepare: {code}2011-02-15 10:23:08,024 25143 TRACE [org.infinispan.interceptors.DistributionInterceptor] (Atomikos:1:) Affected keys in context LocalTxInvocationContext{flags=null}@9866417 are: [] 2011-02-15 10:23:08,024 25143 TRACE [org.infinispan.distribution.DistributionManagerImpl] (Atomikos:1:) Affected keys are empty {code} The prepare, which happens in the Atomikos:1 thread, considers that no keys were modified. {code}2011-02-15 10:23:08,025 25144 TRACE [org.infinispan.interceptors.DistributionInterceptor] (Atomikos:1:) Not performing invalidation! isL1CacheEnabled? false numCallRecipients=0 2011-02-15 10:23:08,025 25144 TRACE [org.infinispan.remoting.rpc.RpcManagerImpl] (Atomikos:1:) dhcp-144-240-29198 broadcasting call PrepareCommand {gtx=GlobalTransaction:<dhcp-144-240-29198>:2:local, modifications=[PutKeyValueCommand{key=key1, value=com.mycompany.testcase.MyDVO@39263b07, putIfAbsent=false, lifespanMillis=-1, maxIdleTimeMillis=-1}, PutKeyValueCommand{key=key2, value=bob85, putIfAbsent=false, lifespanMillis=-1, maxIdleTimeMillis=-1}], onePhaseCommit=true, gtx=GlobalTransaction:<dhcp-144-240-29198>:2:local, cacheName='testCache'} to recipient list [] 2011-02-15 10:23:08,025 25144 TRACE [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Atomikos:1:) Destination list is empty: no need to send message {code} And so, even if the modification list is not null, the destination list, or nodes to replicate to is empty, cos this is derived from the affected keys, which are empty. You could get around the issue if the thread that made the cache operations was the one to do the commit. You'll have to figure out whether that's doable in your Spring/Atomikos set up. In the mean time, I'm checking whether the affected keys could be derived from the modification list. Otherwise, a new feature will be needed to support different threads doing modifications vs doing commits. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira