Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolves a deadlock scenario applying constraint #9110

Merged
merged 4 commits into from Apr 11, 2017

Conversation

tinwelint
Copy link
Member

The scenario, which takes place on database instance applying constraint
creation as an external transaction, looks like this:

  • Transaction T1 creates the constraint index and population P starts
  • Transaction T2 which activates the constraint starts applying
    and now has a read lock on the counts store
  • Check point triggers, wants to rotate counts store and so acquires
    its write lock. It will have to block, but doing so will also blocks
    further read lock requests
  • T2 moves on to activate the constraint. Doing so means first waiting for
    the index to come online
  • P moves on to flip after population, something which includes initializing
    some sample data in counts store for this index. Will block on the counts
    store read lock, completing the deadlock

The solution in this commit breaks the deadlock by having T2 unlock its
read lock on the counts store before activating the constraint, i.e.
as soon as it notices that it is a schema transaction. Schema transactions
will not update the counts store anyway.

The scenario, which takes place on database instance applying constraint
creation as an external transaction, looks like this:

- Transaction T1 creates the constraint index and population P starts
- Transaction T2 which activates the constraint starts applying
  and now has a read lock on the counts store
- Check point triggers, wants to rotate counts store and so acquires
  its write lock. It will have to block, but doing so will also blocks
  further read lock requests
- T2 moves on to activate the constraint. Doing so means first waiting for
  the index to come online
- P moves on to flip after population, something which includes initializing
  some sample data in counts store for this index. Will block on the counts
  store read lock, completing the deadlock

The solution in this commit breaks the deadlock by having T2 unlock its
read lock on the counts store before activating the constraint, i.e.
as soon as it notices that it is a schema transaction. Schema transactions
will not update the counts store anyway.
@tinwelint tinwelint force-pushed the 3.0-apply-constraint-deadlock branch from cab592c to 4ebfb55 Compare March 29, 2017 07:45
@MishaDemianenko MishaDemianenko self-assigned this Mar 29, 2017
public final OtherThreadRule<Void> t3 = new OtherThreadRule<>( "T3" );

@Test
public void shouldNotDeadlock() throws Exception
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we need to add a timeout to this test just in case it will hang


@Test
public void shouldNotDeadlock() throws Exception
{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also we need to add a bit of assertions to the test, now we do not have any

@@ -68,4 +74,15 @@ public boolean visitRelationshipCountsCommand( Command.RelationshipCountsCommand
}
return false;
}

@Override
public boolean visitSchemaRuleCommand( SchemaRuleCommand command ) throws IOException
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also as we just talk, would be nice to have guarding assertion that will fail in case when this assumption will brake

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, this has been added

Copy link
Contributor

@MishaDemianenko MishaDemianenko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

couple of comments, otherwise we can give it a try

@MishaDemianenko
Copy link
Contributor

ping @tinwelint

@tinwelint
Copy link
Member Author

@MishaDemianenko updated

@MishaDemianenko MishaDemianenko merged commit 3c6148d into neo4j:3.0 Apr 11, 2017
@tinwelint tinwelint deleted the 3.0-apply-constraint-deadlock branch December 11, 2017 10:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants