[infinispan-issues] [JBoss JIRA] (ISPN-4569) Inserting into cache with indexing fails for XA transactions

[Radim Vansa (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-4569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988368#comment-12988368 ] 

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)