[
https://issues.jboss.org/browse/ISPN-2362?page=com.atlassian.jira.plugin....
]
Mircea Markus updated ISPN-2362:
--------------------------------
Description:
The NBST functionality leaves place to inconsistencies during removals:
1. the joiner first requests transaction data
2. after all transaction data is integrated (i.e. tx is prepared on the state receiver
node) it requests the rest(data container) of the data
3. in order not to override the data from transactions which is more recent (transactions
at step 1 might commit during step 2), the insertion at 2 happens with putIfAbsent. Whilst
this prevents from overriding newer values (written by transactions), it doesn't guard
against the situation in which the tx at step 1 removed data. So it is possible for
deleted data a to resurrect.
A solution to this inconsistency issue is to use tombstones for the duration of the state
transfer.
was:
The NBST functionality leaves place to inconsistencies during removals:
1. the joiner first requests transaction data
2. after all transaction data is integrated (i.e. tx is prepared on the state receiver
node) it requests the rest of the data (from data container)
3. in order not to override the data from transactions which is more recent (transactions
at step 1 might have been committed during step 2), the data at 2 inserts data in the
cache with putIfAbsent. Whilst this prevents from overriding newer values as written by
transactions, it doesn't guard against the situation in which the tx removed data. So
it is possible for deleted data a to resurrect.
A possible solution to this inconsistency issue is by using tombstones for the duration of
the state transfer.
Remove-inconsistency during NBST
--------------------------------
Key: ISPN-2362
URL:
https://issues.jboss.org/browse/ISPN-2362
Project: Infinispan
Issue Type: Feature Request
Components: State transfer
Affects Versions: 5.2.0.Alpha3
Reporter: Mircea Markus
Assignee: Dan Berindei
Priority: Critical
Fix For: 5.2.0.CR1
The NBST functionality leaves place to inconsistencies during removals:
1. the joiner first requests transaction data
2. after all transaction data is integrated (i.e. tx is prepared on the state receiver
node) it requests the rest(data container) of the data
3. in order not to override the data from transactions which is more recent (transactions
at step 1 might commit during step 2), the insertion at 2 happens with putIfAbsent. Whilst
this prevents from overriding newer values (written by transactions), it doesn't guard
against the situation in which the tx at step 1 removed data. So it is possible for
deleted data a to resurrect.
A solution to this inconsistency issue is to use tombstones for the duration of the state
transfer.
--
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