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

[Dan Berindei (JIRA)]

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

Dan Berindei commented on ISPN-4569:
------------------------------------

I guess it doesn't matter when the actual write to the index is done, but it caught my eye and I wanted to make sure it's not a problem.

It was actually the same with the cluster registry when it was transactional - writing to it just added a synchronization to the running XA transaction. And just like writing to the index, it wasn't at all clear that the cluster registry write was postponed until after the main cache tx had committed :)

> 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
>             Fix For: 7.0.0.Beta1
>
>
> 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)