-
Notifications
You must be signed in to change notification settings - Fork 428
Hive locking #405
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
Hive locking #405
Conversation
Fokko
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a big one, thanks for fixing this @danielcweeks
@syun64 We want to add this to the 0.6.0 as well
| except NoSuchObjectException as e: | ||
| raise NoSuchTableError(f"Table does not exist: {table_name}") from e | ||
| finally: | ||
| open_client.unlock(UnlockRequest(lockid=lock.lockid)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't consider this a blocker, but it'd be nice to have a test to verify that in case of any exception thrown we do actually perform the unlock.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a really hard one because it requires that we've already acquired the lock, but then something happened (timeout?) and the the lock state changed. I'd have to think though how we could replicate that scenario.
This PR adds locking to the hive commit path for tables. The current commit path is unsafe as competing updates may overwrite other clients that are using locking.
This implementation is the most restrictive in that it will fail a commit if it cannot immediately acquire a lock.