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

[Sanne Grinovero (JIRA)]

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

Sanne Grinovero commented on ISPN-4569:
---------------------------------------

yes they should add value. But Infinispan is hijacking the user TX to do other things in it, apparently even at odd lifecycles, and including forcing it to become XA (which implies a need for transaction logs) while the user will not expect this to happen.

{quote}Where is it registered, as a synchronization? (just asking){quote}
I only meant what Hibernate Search does when it's used in the context of Hibernate ORM / JPA. Apparently Manik and Navin coded it differently in Infinispan.

Why is the change to the ServiceRegistry included in the same transaction of the user? they should be independent, or a child transaction at best.

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