SNAP-1950 #361
Open
SNAP-1950 #361
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 3 commits
January 31, 2018 21:18
This is to avoid a race where GII first takes pendingTXRegionState lock and then tries to apply the operation which in turn tries to create the TXRegionState. In case of BatchMessage, we first create the TXRegionState and then try to take lock on pendingTXRegionState. This causes cyclic dependency and deadlock
added 2 commits
February 1, 2018 12:34
Instead of NonReentrantReadWriteLock, use StoppableReentrantReadWriteLock
added 5 commits
February 1, 2018 17:54
In case of co-ordinator wait for initialization
In the TXRegionState constructor check if write lock already taken In that case don't try to take lock again.
sumwale
reviewed
Jun 25, 2018
| if (!r.isInitialized() && r.getImageState().lockPendingTXRegionStates(true, false)) { | ||
| lockedRegions.add(r); | ||
| } | ||
| }*/ |
There was a problem hiding this comment.
commented portion can be removed to avoid confusion
| region.getImageState().lockPendingTXRegionStates(true, false)) { | ||
| //lockedRegions.add(region); | ||
| lockedPendingTXregionState = true; | ||
| } |
There was a problem hiding this comment.
cleaner to do "boolean lockPendingTXRegionState = !region.isInitialized() && region.getImageState().lock..."
|
|
||
| boolean alreadyLocked = imgState.isWriteLockedBySameThread(); | ||
| if (!r.isInitialized() | ||
| && (alreadyLocked || imgState.lockPendingTXRegionStates(true, false))) { | ||
| try { |
There was a problem hiding this comment.
Since the lock can be taken multiple times by same thread, won't it be better to make this a ReentrantReadWriteLock instead of "isWriteLockedBySameThread" check? The block inside will add TXRegionState in pending list and initialize pendingTXOps lists which I think is required.
ashetkar
force-pushed
the
SNAP-1950-2
branch
from
6f2602c
to
9404c94
Compare
sumwale
force-pushed
the
snappy/master
branch
2 times, most recently
from
337768c
to
ec453a6
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is to avoid a race where GII first takes pendingTXRegionState lock
and then tries to apply the operation which in turn tries to create
the TXRegionState.
In case of BatchMessage, we first create the TXRegionState and then try
to take lock on pendingTXRegionState. This causes cyclic dependency and
deadlock
Changes proposed in this pull request
(Fill in the changes here)
Patch testing
(Fill in the details about how this patch was tested)
ReleaseNotes changes
(Does this change require an entry in ReleaseNotes? If yes, has it been added to it?)
Other PRs
(Does this change require changes in other projects- snappydata, spark, spark-jobserver, aqp? Add the links of PR of the other subprojects that are related to this change)