[
https://issues.jboss.org/browse/ISPN-4569?page=com.atlassian.jira.plugin....
]
Sanne Grinovero commented on ISPN-4569:
---------------------------------------
Merged the ClusterRegistry improvement, but FYI {{QueryInterceptor.visitPrepareCommand()}}
doesn't actually _write_ to the index but pushed the Work stack the Search engine. The
engine then applies the same strategy as it applies with ORM/JPA: details depend on the
transactions configuration, but in this case it would register a TX Synchronization to be
applied only on successful commit.
In other words, I think I can reject ISPN-4597 although it wasn't clear to me either
how that was done :-)
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)