Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1130493

Summary: Inserting into cache with indexing fails for XA transactions
Product: [JBoss] JBoss Data Grid 6 Reporter: Dan Berindei <dberinde>
Component: InfinispanAssignee: Tristan Tarrant <ttarrant>
Status: CLOSED CURRENTRELEASE QA Contact: Martin Gencur <mgencur>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.3.0CC: gsheldon, jdg-bugs, mhusnain, rvansa, vjuranek
Target Milestone: ER2   
Target Release: 6.3.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Previously in Red Hat JBoss Data Grid, when a transactional cache was configured as an XA resource (useSynchronization="false") and indexing is enabled on this cache, inserting an entry into this cache may fail due to deadlock between this cache and internal caches. This deadlock occurs under race conditions and only once per a type (class) of value. This is fixed in JBoss Data Grid 6.3.1 and the transactional cache works as expected when configured as an XA resource and with indexing enabled.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2015-01-26 14:05:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dan Berindei 2014-08-15 12:04:12 UTC 
If I setup XA transactions in ClusteredQueryDslConditionsTest using

cacheCfg.transaction().transactionMode(TransactionMode.TRANSACTIONAL).useSynchronization(false);

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.