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

Make SlaveLockClient cope better with ComExceptions #6102

Merged
merged 7 commits into from Dec 18, 2015
Merged

Make SlaveLockClient cope better with ComExceptions #6102

merged 7 commits into from Dec 18, 2015

Conversation

chrisvest
Copy link
Contributor

Be aware that packages and classes have moved around a lot in newer branches, so great care should be taking when merging this forward.

It was an indirect way of reading the lock_read_timeout HA setting lazily or something.
Who knows why it was introduced in the first place.
These methods were never used anywhere, and didn't quite make sense anyway.
We already use the `releaseAll` method anywhere it matters.
…communication failures

And also add a bunch of tests for these failure modes.

The DistributedLockFailureException extends the user-facing TransientTransactionFailureExcpetion, so user-code can actually catch and deal with it.
It is also more descriptive, because a ComException doesn't really say much that is actually useful and actionable to the user.
Especially since they have no idea that it can happen in the first place, and - it being a RuntimeException - pop up pretty much anywhere.
davidegrohmann added a commit that referenced this pull request Dec 18, 2015
Make SlaveLockClient cope better with ComExceptions
@davidegrohmann davidegrohmann merged commit ac2a03d into neo4j:2.2 Dec 18, 2015
@davidegrohmann davidegrohmann deleted the 2.2-locks-and-coms branch December 18, 2015 12:45
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

4 participants