Bug 1130493 - Inserting into cache with indexing fails for XA transactions
Summary: Inserting into cache with indexing fails for XA transactions
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Data Grid 6
Classification: JBoss
Component: Infinispan
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ER2
: 6.3.1
Assignee: Tristan Tarrant
QA Contact: Martin Gencur
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-15 12:04 UTC by Dan Berindei
Modified: 2015-01-26 14:05 UTC (History)
5 users (show)

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.
Clone Of:
Environment:
Last Closed: 2015-01-26 14:05:39 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker ISPN-4569 0 Major Resolved Inserting into cache with indexing fails for XA transactions 2017-05-05 09:32:24 UTC

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.
Note You need to log in before you can comment on or make changes to this bug.