[ https://jira.jboss.org/jira/browse/ISPN-419?page=com.atlassian.jira.plugi... ] Galder Zamarreno updated ISPN-419: ---------------------------------- Summary: Transactional AtomicHashMap modifications are lost when persisting (was: Transactional AtomicHashMap modifications are lost when replicating or persisting) Description: When an AtomicHashMap stored in a cache store using transactions, the actual modification is lost. This is due to duplication of modifications being fired. After the 1st modification has been sent to another node or cache store, its delta is reset and when the 2nd modification comes, it finds delta as being null and hence that's what's replicated stored. was: When an AtomicHashMap is either replicate or stored in a cache store using transactions, the actual modification is lost. This is due to duplication of modifications being fired. After the 1st modification has been sent to another node or cache store, its delta is reset and when the 2nd modification comes, it finds delta as being null and hence that's what's replicated stored. The issue only affects persistence via cache store. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/ISPN-419?page=com.atlassian.jira.plugi... ] Galder Zamarreno commented on ISPN-419: --------------------------------------- Fixed by making sure deltas are only used for repl/dist and when storing to cache store taking the underlying map of the atomic hash map and marshalling that. Added a test to verify that merging works correctly in a clustered env as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira