5:58 p.m.
eagerLockSingleNode="true" and rehasing
---------------------------------------
Key: ISPN-1007
URL: https://issues.jboss.org/browse/ISPN-1007
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 4.2.1.FINAL
Reporter: Mircea Markus
Assignee: Mircea Markus
Fix For: 4.2.2.BETA1, 5.0.0.FINAL
When eagerLockSingleNode="true", if the main data owner of a key changes during
a transaction then the k might end up in inconsistent state.
A solution to avoid this is:
- on topology change, if a eagerLockSingleNode is enabled, iterate over all
transactions's keys
- if the main owner for a key has changed then just mark the tx for rollback
This way, on next operation for that transaction an exception should be thrown, e.g.
TxRollbackOnlyException
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:11 p.m.
New subject: [JBoss JIRA] Updated: (ISPN-1007) rehashing inconsistency when eagerLockSingleNode enabled
[
https://issues.jboss.org/browse/ISPN-1007?page=com.atlassian.jira.plugin....
]
Mircea Markus updated ISPN-1007:
--------------------------------
Summary: rehashing inconsistency when eagerLockSingleNode enabled (was:
eagerLockSingleNode="true" and rehasing)
rehashing inconsistency when eagerLockSingleNode enabled
--------------------------------------------------------
Key: ISPN-1007
URL: https://issues.jboss.org/browse/ISPN-1007
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 4.2.1.FINAL
Reporter: Mircea Markus
Assignee: Mircea Markus
Fix For: 4.2.2.BETA1, 5.0.0.FINAL
When eagerLockSingleNode="true", if the main data owner of a key changes during
a transaction then the k might end up in inconsistent state.
A solution to avoid this is:
- on topology change, if a eagerLockSingleNode is enabled, iterate over all
transactions's keys
- if the main owner for a key has changed then just mark the tx for rollback
This way, on next operation for that transaction an exception should be thrown, e.g.
TxRollbackOnlyException
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:49 p.m.
New subject: [JBoss JIRA] Commented: (ISPN-1007) rehashing inconsistency when eagerLockSingleNode enabled
[
https://issues.jboss.org/browse/ISPN-1007?page=com.atlassian.jira.plugin....
]
Manik Surtani commented on ISPN-1007:
-------------------------------------
I would go with the latter for now. Simple check during a prepare.
rehashing inconsistency when eagerLockSingleNode enabled
--------------------------------------------------------
Key: ISPN-1007
URL: https://issues.jboss.org/browse/ISPN-1007
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 4.2.1.FINAL
Reporter: Mircea Markus
Assignee: Mircea Markus
Fix For: 4.2.2.BETA1, 5.0.0.FINAL
When eagerLockSingleNode="true", if the main data owner of a key changes during
a transaction then the k might end up in inconsistent state.
A solution to avoid this is:
- on topology change, if a eagerLockSingleNode is enabled, iterate over all
transactions's keys
- if the main owner for a key has changed then just mark the tx for rollback
This way, on next operation for that transaction an exception should be thrown, e.g.
TxRollbackOnlyException
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:02 p.m.
New subject: [JBoss JIRA] Updated: (ISPN-1007) rehashing inconsistency when eagerLockSingleNode enabled
[
https://issues.jboss.org/browse/ISPN-1007?page=com.atlassian.jira.plugin....
]
Manik Surtani updated ISPN-1007:
--------------------------------
Fix Version/s: 4.2.2.FINAL
5.0.0.CR1
rehashing inconsistency when eagerLockSingleNode enabled
--------------------------------------------------------
Key: ISPN-1007
URL: https://issues.jboss.org/browse/ISPN-1007
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 4.2.1.FINAL
Reporter: Mircea Markus
Assignee: Mircea Markus
Fix For: 4.2.2.BETA1, 4.2.2.FINAL, 5.0.0.CR1, 5.0.0.FINAL
When eagerLockSingleNode="true", if the main data owner of a key changes during
a transaction then the k might end up in inconsistent state.
A solution to avoid this is:
- on topology change, if a eagerLockSingleNode is enabled, iterate over all
transactions's keys
- if the main owner for a key has changed then just mark the tx for rollback
This way, on next operation for that transaction an exception should be thrown, e.g.
TxRollbackOnlyException
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:45 p.m.
New subject: [JBoss JIRA] Updated: (ISPN-1007) rehashing inconsistency when eagerLockSingleNode enabled
[
https://issues.jboss.org/browse/ISPN-1007?page=com.atlassian.jira.plugin....
]
Mircea Markus updated ISPN-1007:
--------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/272
rehashing inconsistency when eagerLockSingleNode enabled
--------------------------------------------------------
Key: ISPN-1007
URL: https://issues.jboss.org/browse/ISPN-1007
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 4.2.1.FINAL
Reporter: Mircea Markus
Assignee: Mircea Markus
Fix For: 4.2.2.BETA1, 4.2.2.FINAL, 5.0.0.CR1, 5.0.0.FINAL
When eagerLockSingleNode="true", if the main data owner of a key changes during
a transaction then the k might end up in inconsistent state.
A solution to avoid this is:
- on topology change, if a eagerLockSingleNode is enabled, iterate over all
transactions's keys
- if the main owner for a key has changed then just mark the tx for rollback
This way, on next operation for that transaction an exception should be thrown, e.g.
TxRollbackOnlyException
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:47 p.m.
New subject: [JBoss JIRA] Commented: (ISPN-1007) rehashing inconsistency when eagerLockSingleNode enabled
[
https://issues.jboss.org/browse/ISPN-1007?page=com.atlassian.jira.plugin....
]
Mircea Markus commented on ISPN-1007:
-------------------------------------
@Manik, there's only wan suggested solution composed of two steps :-) I've
implemented it, see the pull request
rehashing inconsistency when eagerLockSingleNode enabled
--------------------------------------------------------
Key: ISPN-1007
URL: https://issues.jboss.org/browse/ISPN-1007
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 4.2.1.FINAL
Reporter: Mircea Markus
Assignee: Mircea Markus
Fix For: 4.2.2.BETA1, 4.2.2.FINAL, 5.0.0.CR1, 5.0.0.FINAL
When eagerLockSingleNode="true", if the main data owner of a key changes during
a transaction then the k might end up in inconsistent state.
A solution to avoid this is:
- on topology change, if a eagerLockSingleNode is enabled, iterate over all
transactions's keys
- if the main owner for a key has changed then just mark the tx for rollback
This way, on next operation for that transaction an exception should be thrown, e.g.
TxRollbackOnlyException
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:59 p.m.
New subject: [JBoss JIRA] Commented: (ISPN-1007) rehashing inconsistency when eagerLockSingleNode enabled
[
https://issues.jboss.org/browse/ISPN-1007?page=com.atlassian.jira.plugin....
]
Mircea Markus commented on ISPN-1007:
-------------------------------------
Another one on locks not being released: https://issues.jboss.org/browse/ISPN-1074
rehashing inconsistency when eagerLockSingleNode enabled
--------------------------------------------------------
Key: ISPN-1007
URL: https://issues.jboss.org/browse/ISPN-1007
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 4.2.1.FINAL
Reporter: Mircea Markus
Assignee: Mircea Markus
Fix For: 4.2.2.BETA1, 4.2.2.FINAL, 5.0.0.CR1, 5.0.0.FINAL
When eagerLockSingleNode="true", if the main data owner of a key changes during
a transaction then the k might end up in inconsistent state.
A solution to avoid this is:
- on topology change, if a eagerLockSingleNode is enabled, iterate over all
transactions's keys
- if the main owner for a key has changed then just mark the tx for rollback
This way, on next operation for that transaction an exception should be thrown, e.g.
TxRollbackOnlyException
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:48 a.m.
New subject: [JBoss JIRA] Resolved: (ISPN-1007) rehashing inconsistency when eagerLockSingleNode enabled
[
https://issues.jboss.org/browse/ISPN-1007?page=com.atlassian.jira.plugin....
]
Galder Zamarreño resolved ISPN-1007.
------------------------------------
Resolution: Done
rehashing inconsistency when eagerLockSingleNode enabled
--------------------------------------------------------
Key: ISPN-1007
URL: https://issues.jboss.org/browse/ISPN-1007
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 4.2.1.FINAL
Reporter: Mircea Markus
Assignee: Mircea Markus
Fix For: 4.2.2.BETA1, 4.2.2.FINAL, 5.0.0.CR1, 5.0.0.FINAL
When eagerLockSingleNode="true", if the main data owner of a key changes during
a transaction then the k might end up in inconsistent state.
A solution to avoid this is:
- on topology change, if a eagerLockSingleNode is enabled, iterate over all
transactions's keys
- if the main owner for a key has changed then just mark the tx for rollback
This way, on next operation for that transaction an exception should be thrown, e.g.
TxRollbackOnlyException
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4740
days inactive
4771
days old
infinispan-issues@lists.jboss.org
7 comments
3 participants
participants (3)
-
Galder Zamarreño (JIRA) -
Manik Surtani (JIRA)
-
Mircea Markus (JIRA)