- 
        1. Cache inserts inside a transaction are not propagated across the clustermircea.markus Feb 3, 2011 8:08 AM (in response to sudheerk84)If you want your data/locks to be propagated as your tx progresses use eager locking. 
- 
        2. Re: Cache inserts inside a transaction are not propagated across the clustersudheerk84 Feb 3, 2011 8:12 AM (in response to mircea.markus)i have used eager locking true. useEagerLocking="true". Even after the transaction commits without any exceptions , I see the second node doesnt get updated. Its not only the lock, The cache update itself is not propagated to another node. 
- 
        3. Re: Cache inserts inside a transaction are not propagated across the clustermircea.markus Feb 3, 2011 8:16 AM (in response to sudheerk84)how many nodes do you have in the cluster? Distribution won't spread the data to all caches. E.g. if your cluster is {A,B,C} if you put k on A it will get replicated on 2(numOwners) nodes only, e.g. A and B . Now if you look at C data won't be there. Unless you do a C.get, which would take it from a remote node (A or B in this example). 
- 
        4. Re: Cache inserts inside a transaction are not propagated across the clustersudheerk84 Feb 3, 2011 8:29 AM (in response to mircea.markus)yes Mircea. i am only using two nodes . I am also verifying by checking cache.get() . Everything works fine(cache.get() returns updated value) when i do my puts outside teh transaction. . The only problem is when i do i cache.put() inside a transaction , and i do a cache.get() in another nodes it shows the old value. cache.get() in the same node gives teh udpated value. When i remove two lines of code - txnManager.begin() and txnManager.commit() - replication happens fine as expected across cluster. So i doubt that teh issue could be in transaction commit , which does only local updation and doesnt propagate it across cluster. 
- 
        5. Re: Cache inserts inside a transaction are not propagated across the clustermircea.markus Feb 3, 2011 8:34 AM (in response to sudheerk84)Very strange. Can you use the dummy tx manager and see if ti works with that? Just set the tx manager lookup attribute to org.infinispan.transaction.lookup.DummyTransactionManagerLookup 
- 
        6. Cache inserts inside a transaction are not propagated across the clustersudheerk84 Feb 3, 2011 10:05 AM (in response to mircea.markus)Yes i tried as per your suggestion and it works fine with DummyTransactionmanager. So could the issue be with Atomikos transaction manager ? I am using atomikos because i need a JTA complaint transaction manager because i need to maintain tranasctions between multiple resources namely mysql database and inifinispan cache. 
- 
        7. Cache inserts inside a transaction are not propagated across the clustersudheerk84 Feb 3, 2011 11:18 AM (in response to sudheerk84)I get a feeling this is not a bug with atomikos , instead something needs to be done from infinispan. The reason for teh above statement is - Infinispan is able to understand transaction commit ,. The changes are relefected in the local VM . Only changes fail to propagate across teh cluster. Is there any kind of debugging i can do on teh infinispan code ? Anycheck points a can check to see if clsuter propagation code is called . 
- 
        8. Cache inserts inside a transaction are not propagated across the clustersudheerk84 Feb 3, 2011 12:40 PM (in response to sudheerk84)I did try extending to some more usescase using atomikos transaction manager - (all usecases by running a loop) 1. 2 threads within the same Vm - are able to see teh changes in cluster. 2. Two JVMs on the same node - are not able to see changes in cache values inside a transaction. 3. Two jvms on different nodes are also not able to see cache modifications Another thing I noticed is when i start a JVM on a seperate machine - teh first cache.get() - values is teh updated value - from the lastest commited transaction. So i though it is caching after the first acces and tried to disable L1 caching. But no luck. Only first iteration value is teh updated one(commited by teh last transaction) . My loop is as follows for (;;) { Thread.currentThread().sleep(3 * 1000); System.out.println("Cache content " + cache.get("key2")); } The first iteration gives teh updated value (one commited by teh transaction in another node ) . Later terations keep giving the old value . and do not see changes made in another node. 
- 
        9. Cache inserts inside a transaction are not propagated across the clustersudheerk84 Feb 4, 2011 5:40 AM (in response to sudheerk84)I have figured oen more intesreting thing When i use mode as replication - everything works fine , and commits within a transactiona re visible to otehr nodes. the issue is only with mode = distribution , where transaction commits are not visvible to other nodes. Could this be a bug ? 
- 
        10. Cache inserts inside a transaction are not propagated across the clustergalder.zamarreno Feb 10, 2011 12:20 PM (in response to sudheerk84)Sudheer, I'd suggest you create a test case that we can run to see the problem that you're having. Once you have that, please create a JIRA with the test case and we'll look into it. 
- 
        11. Cache inserts inside a transaction are not propagated across the clustersudheerk84 Feb 10, 2011 12:25 PM (in response to galder.zamarreno)Sure Galder. I will create a testcase and update the same. 
- 
        12. Cache inserts inside a transaction are not propagated across the clustersudheerk84 Feb 11, 2011 4:54 AM (in response to sudheerk84)I have created the issue in jira along with sample code attached where the issue can be reproduced. 
- 
        13. Cache inserts inside a transaction are not propagated across the clustergalder.zamarreno Feb 17, 2011 10:35 AM (in response to sudheerk84)Issue solved. You should try with 4.2.1.CR2. 
- 
        14. Cache inserts inside a transaction are not propagated across the clusterbrenuart Feb 17, 2011 10:39 AM (in response to galder.zamarreno)BTW, Galder, could you explain me how I can upgrade JBoss AS 6 to make use of this latest version of Infinispan ? 
 
     
     
    