Bug 1080314 - Lock acquired forever with delayed PrepareCommand
Summary: Lock acquired forever with delayed PrepareCommand
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Data Grid 6
Classification: JBoss
Component: Infinispan
Version: 6.2.1
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ER2
: 6.3.0
Assignee: Dan Berindei
QA Contact: Martin Gencur
URL:
Whiteboard:
Depends On:
Blocks: 1092056
TreeView+ depends on / blocked
 
Reported: 2014-03-25 07:25 UTC by Radim Vansa
Modified: 2015-01-26 14:05 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-01-26 14:05:37 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker ISPN-4131 0 Critical Resolved Lock acquired forever with delayed PrepareCommand 2016-11-04 08:29:58 UTC

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.


Note You need to log in before you can comment on or make changes to this bug.