[
https://issues.jboss.org/browse/ISPN-4569?page=com.atlassian.jira.plugin....
]
Radim Vansa commented on ISPN-4569:
-----------------------------------
The problem is that ServiceRegistry uses transactional cache, and therefore, you start a
transaction while executing prepare for another transaction. If those two transactions
modify the same key, you have the deadlock. I don't blame you for not realizing that,
though :)
The correct solution would be (IMO) to let the code executing prepare join the
transaction, if it needs to execute another distributed code. However, that would result
in sending another PrepareCommand to another nodes, sharing the actually modified state
(if we expect repeatable reads across cluster) and possibly a cascade of another
operations... And the consequences terrify me a bit :) But the other option is to prohibit
code performing the prepare starting a new transactions - I am not sure how the current
implementation would cope with that.
Inserting into cache with indexing fails for XA transactions
------------------------------------------------------------
Key: ISPN-4569
URL:
https://issues.jboss.org/browse/ISPN-4569
Project: Infinispan
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Embedded Querying, Transactions
Affects Versions: 7.0.0.Alpha5
Reporter: Radim Vansa
Assignee: Dan Berindei
If I setup XA transactions in {{ClusteredQueryDslConditionsTest}} using
{code}
cacheCfg.transaction().transactionMode(TransactionMode.TRANSACTIONAL).useSynchronization(false);
{code}
the test fails. The reason is in deadlock while updating {{ScopedKey}} in
__cluster_registry_cache__ : It seems that on originator we create transaction with
modified inserted key and the {{ScopedKey}} for inserted class, and send it in two prepare
commands to the other node. In the {{ScopedKey}}-prepare, the lock is acquired, but the
regular prepare on the other node does not see it (it is not committed yet) and also tries
to update this {{ScopedKey}} in __cluster_registry_cache__ . This fails with lock
timeout, as the commit is waiting on the regular prepare to finish.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)