[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=12988431#comment-12988431 ] 

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

[~sannegrinovero] you are right, the cluster registry is an implementation detail, and we never describe the cluster registry as joining an ongoing transaction. However, the cluster registry cache registers itself as a synchronization, so it doesn't force the tx to become XA.

I see the indexing is done in the {{QueryInterceptor.visitPrepareCommand()}}, so indexing is done during the Infinispan cache's prepare, regardless of whether it's an XA resource of a synchronization. This is probably too early, as the TM can very well roll back the tx after a successful prepare.

However, it would be impossible to access the cluster registry during commit unless we start an independent tx in cluster registry operations, so that should be the first priority.

> 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)