[HUDI-8490] Implicit lock provider use different lock key scheme #12220
+55
−43
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.
Change Logs
code + test
Impact
For implicit lock provider
org.apache.hudi.aws.transaction.lock.DynamoDBBasedImplicitPartitionKeyLockProvider
andorg.apache.hudi.client.transaction.lock.ZookeeperBasedImplicitBasePathLockProvider
, inside the lock key (for zookeeper) / partition key (for ddb) it contains substring<tablename>-<hash of table basepath>
.This is problematic in case of alter table rename, some writers are using the old lock key while others are using the new one, which leads to concurrency bug as the lock fails to synchronize operations from concurrent operators.
Alter rename should not have coupling with locks, so to remove the dependency, we removed the table name from the lock key for both implicit ddb and zookeeper lock provider.
Risk level (write none, low medium or high below)
Low
Documentation Update
We should update the merge into doc about this new restriction.
Contributor's checklist