[
https://issues.jboss.org/browse/ISPN-4091?page=com.atlassian.jira.plugin....
]
Erik Salter updated ISPN-4091:
------------------------------
Description:
The current state transfer mechanism will ask the backup segments for transaction and
state information. However, this breaks if there is a pessimistic transaction executing
on the primary data owner, Consider the following use case:
A new owner joins and sources the ongoing transactions and data for key k from the backup.
Meanwhile, a local transaction has started on the primary owner for k, but has not
prepared on any remote nodes. So the new node does not know about the ongoing
transaction. While that's going on, a new tx starts on the new owner. Since these
are pessimistic, the new transaction will acquires the lock for the same key.
So we can have data inconsistency.
The state transfer mechanism should prefer to source the transaction and state information
from the primary owner. This should cover all cases: if the originator is not the primary
owner, then any (backup) locks must be replicated to all the owners, either directly
during the tx or during a previous state transfer.
was:
The current state transfer mechanism will ask the backup segments for transaction and
state information. However, this breaks if there is a pessimistic transaction executing
on the primary data owner, Consider the following use case:
A new owner joins and sources the ongoing transactions and data for key k from the backup.
Meanwhile, a local transaction has started on the primary owner for k, but has not
prepared on any remote nodes. So the new node does not know about the ongoing
transaction. While that's going on, a new tx starts on the new owner. Since these
are pessimistic, the new transaction will acquires the lock for the same key.
So we can have data inconsistency.
The state transfer mechanism should prefer to source the transaction and state information
from the primary owner. This should cover all cases: if the originator is not the primary
owner, then any (backup) locks must be replicated to all the owners, either directly
during the tx or during a previous state transfer.
[13:26] <dberindei> I think asking the primary owner should be enough
Transactions and data should prefer to be sourced from a primay
owner
---------------------------------------------------------------------
Key: ISPN-4091
URL:
https://issues.jboss.org/browse/ISPN-4091
Project: Infinispan
Issue Type: Bug
Components: State Transfer
Affects Versions: 5.2.7.Final
Reporter: Erik Salter
Assignee: Dan Berindei
The current state transfer mechanism will ask the backup segments for transaction and
state information. However, this breaks if there is a pessimistic transaction executing
on the primary data owner, Consider the following use case:
A new owner joins and sources the ongoing transactions and data for key k from the
backup. Meanwhile, a local transaction has started on the primary owner for k, but has
not prepared on any remote nodes. So the new node does not know about the ongoing
transaction. While that's going on, a new tx starts on the new owner. Since these
are pessimistic, the new transaction will acquires the lock for the same key.
So we can have data inconsistency.
The state transfer mechanism should prefer to source the transaction and state
information from the primary owner. This should cover all cases: if the originator is not
the primary owner, then any (backup) locks must be replicated to all the owners, either
directly during the tx or during a previous 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