[ https://issues.jboss.org/browse/ISPN-2312?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-2312: -------------------------------- Description: This happens for transactions that arrive via state transfer. The view id of these transactions is currently wrong - it should be the view id in which they were created instead of the current view id at the time they were transferred. AbstractTxLockingInterceptor.lockKeyAndCheckOwnership relies on this and consequently does not work correctly for transferred transactions. Also TransactionTable listens for JGroup view changes instead of CacheTopology updates. This is another reason minViewId calculation is wrong. was: This happens for transactions that arrive via state transfer. The view id of these transactions is currently wrong - it should be the view id in which they were created instead of the current view id at the time they were transferred. TransactionTable.lockKeyAndCheckOwnership relies on this and consequently does not work correctly for transferred transactions. Also TransactionTable listens for JGroup view changes instead of CacheTopology updates. This is another reason minViewId calculation is wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-2312?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-2312: -------------------------------- Description: This happens for transactions that arrive via state transfer. The view id of these transactions is currently wrong - it should be the view id in which they were created instead of the current view id at the time they were transferred. AbstractTxLockingInterceptor.lockKeyAndCheckOwnership relies on this and consequently does not work correctly for transferred transactions. Also TransactionTable listens for JGroup view changes instead of CacheTopology updates. This is another reason minViewId calculation is wrong. Another aspect that needs to be considered is the topology id does not change if the update is not caused by a rebalance. In this case the topologyId comparison in AbstractTxLockingInterceptor.lockKeyAndCheckOwnership must not be strict. was: This happens for transactions that arrive via state transfer. The view id of these transactions is currently wrong - it should be the view id in which they were created instead of the current view id at the time they were transferred. AbstractTxLockingInterceptor.lockKeyAndCheckOwnership relies on this and consequently does not work correctly for transferred transactions. Also TransactionTable listens for JGroup view changes instead of CacheTopology updates. This is another reason minViewId calculation is wrong. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-2312?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2312: -------------------------------- Priority: Critical (was: Major) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira