[infinispan-issues] [JBoss JIRA] (ISPN-5076) Pessimistic transactions can lose their locks when the primary owner changes
Dan Berindei (JIRA)
issues at jboss.org
Fri Dec 19 10:25:29 EST 2014
[ https://issues.jboss.org/browse/ISPN-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029018#comment-13029018 ]
Dan Berindei commented on ISPN-5076:
------------------------------------
This is not a problem if the new primary owner just joined, as it will receive the tx data via state transfer and register backup locks before acquiring any locks. But state transfer won't transfer the transaction information (and register backup locks) to an existing backup owner, only to new owners.
We could require existing backup owners to request locally-originated txs from the primary owner at the beginning of a rebalance. This will slightly increase the amount of time transactions are blocked at the beginning of the rebalance, but it should be easy to implement.
We could also modify the ConsistentHashFactory contract to require implementations to only replace the primary owner with a joiner when rebalancing. ReplicatedConsistentHashFactory definitely doesn't do it now, and the other 4 are very likely to also need adjustments, so this would likely be harder to do than the first option.
> Pessimistic transactions can lose their locks when the primary owner changes
> ----------------------------------------------------------------------------
>
> Key: ISPN-5076
> URL: https://issues.jboss.org/browse/ISPN-5076
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.2.Final, 7.1.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 7.0
> Fix For: 7.1.0.Final
>
>
> In a pessimistic cache, if a transaction {{T1}} has a {{put(k, v)}} operation and the primary owner of the key is the originator, the lock is acquired on the originator but it is not replicated to on the backup(s).
> If one of the backup owners becomes the primary owner, it will allow another transaction {{T2}} to lock (and update) key {{k}} before it receives the one-phase prepare command from the originator of {{T1}}.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
More information about the infinispan-issues
mailing list