[ https://issues.jboss.org/browse/ISPN-927?page=com.atlassian.jira.plugin.s... ] Sudheer Krishna commented on ISPN-927: -------------------------------------- I have attached the source code. teh source can be attached as maven projects. The code uses spring and atomikos for transaction management. cache-framework - custom wrapper around infinispan. transaction-framework - custom wrapper around atomikos. testcase - code containing runnable code. starting node 1 - com.mycompany.testcase.Main -Dapp.name=vm1 -Djgroups.bind_addr=SITE_LOCAL starting node 2 - com.mycompany.testcase.Vm2 -Dapp.name=vm2 -Djgroups.bind_addr=SITE_LOCAL Node 1 - creates a cache(testCache) and keeps updating the values inside a transaction. It has two keys - one simple key which is a string and the other one is a POJO Node 2- Just access the cache and tries to print the values into the console. Issue ----- The infinispan cache xml is inside the resources folder. When run in distribution mode the updates made by node 1 is not visible to node 2. changing the mode to replication everything works fine. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-927?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño updated ISPN-927: ---------------------------------- Fix Version/s: 4.2.1.CR2 5.0.0.ALPHA3 5.0.0.Final I'm having checking this out, it looks odd. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ 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

[ https://issues.jboss.org/browse/ISPN-927?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño updated ISPN-927: ---------------------------------- Fix Version/s: (was: 5.0.0.Final) (was: 5.0.0.ALPHA3) Affects Version/s: 4.2.1.CR1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-927?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño commented on ISPN-927: --------------------------------------- @Manik, nope. The IC is looked up from the thread local, not from the transaction table. And it's the IC that you're interested about cos affectedKeys is a property of IC, not of the local transaction. If affectedKeys belonged to the local transaction, then assuming the local transaction was found fine, the code would work. But since it relies on a thread local, once you switch threads, bye bye affected keys. I should be able to replicate this issue with any TM if my reasoning is right. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-927?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño commented on ISPN-927: --------------------------------------- @Sudheer, at least in your set up yeah. Just enable logging and add thread information to the log and you should clearly see that. I'm not sure about the JTA requirements here, Mircea, the transactions expert in the team should be able to clarify this further. Btw, here's test using the dummy TM that replicates your issue: http://pastebin.com/TQ69GiZe It fails with: {code}java.lang.AssertionError: expected:<v0-testCommitInDifferentThread> but was:<null{code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-927?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño commented on ISPN-927: --------------------------------------- @Sudheer, I have a fix for it: https://github.com/infinispan/infinispan/pull/166 It'll be included in 4.2.1.CR2. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-927?page=com.atlassian.jira.plugin.s... ] Sudheer Krishna commented on ISPN-927: -------------------------------------- The reason I am using static reference is - the transaction lookup class is instantiated by infinispan. And my transaction manager is instantiated by spring container. And i wanted to ensure that spring container instantiates transactionmanager bean before defaultcachemanager() constructor is called which internally uses the transactionlookup class. Also I am not using OSGI for hot deployment. I am not using any containers like tomcat/jboss etc , my code is standalone server. But I understand your concern with statics in hot/re deployments. Thanks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-927?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño commented on ISPN-927: --------------------------------------- Good stuff Sudheer, I added an FAQ entry to http://community.jboss.org/docs/DOC-13439 Btw, it's fairly obvious that the commits where happening in a separate thread. Simply add %t to the logging pattern used in your log4j.xml so that each line prints information on which thread executes the operation, and you can see it immediately. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-927?page=com.atlassian.jira.plugin.s... ] Mircea Markus resolved ISPN-927. -------------------------------- Resolution: Done -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira