Bug 1080314

Summary: Lock acquired forever with delayed PrepareCommand
Product: [JBoss] JBoss Data Grid 6 Reporter: Radim Vansa <rvansa>
Component: InfinispanAssignee: Dan Berindei <dberinde>
Status: CLOSED CURRENTRELEASE QA Contact: Martin Gencur <mgencur>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.2.1CC: dberinde, jdg-bugs, ttarrant
Target Milestone: ER2   
Target Release: 6.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-01-26 14:05:37 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:
Bug Depends On:    
Bug Blocks: 1092056    

Description Radim Vansa 2014-03-25 07:25:44 UTC 
Distributed transactional cache:

1. A sends Prepare to B
2. B receives Prepare, but due to ongoing ST it is blocked
3. B replication timeout elapses
4. B sends Rollback, this does not find the TX as Prepare was not executed yet. The transaction is put into completedTransactions.
5. Completed transactions timeout elapses. This is by default 15 seconds, way shorter than ST timeout (due to which the Prepare was blocked)
6. Prepare is executed on B, acquiring lock on K

Nobody will rollback the TX as originator thinks it was already rolled back.
Result: key K will be locked forever, all attempts to update/remove it will fail.
Comment 1 Radim Vansa 2014-03-25 07:29:10 UTC 
As a workaround transaction.completionTxTimeout should be increased to value larger than state transfer timeout.
This option is not available for server mode, but transactions are not supported there anyway.