rangareddy commented on issue #16814: URL: https://github.com/apache/hudi/issues/16814#issuecomment-5391601898
**Findings: the documentation has since been updated. This can be closed.** An earlier note on this issue (July 2026) recorded that the concurrency-control docs covered the Storage-based, ZooKeeper, HiveMetastore, DynamoDB and FileSystem lock providers but not the implicit-partition-key variant. That is no longer the case. [docs/concurrency_control#distributed-locking](https://hudi.apache.org/docs/concurrency_control#distributed-locking) now documents six providers, including **"DynamoDB-Based Lock Provider with Implicit Partition Key"**, and explains the mechanism: > Rather than reading `hoodie.write.lock.dynamodb.partition_key`, it derives the key from the table's base path: the 64-bit xxHash of that path. along with the rationale - two tables sharing a name under different paths would otherwise resolve to the same lock and serialize writers that never touch the same data, so deriving the key from the base path keeps it unique per table with no per-table configuration. That covers what this ticket asked for. The implementation it documents is `hudi-aws/src/main/java/org/apache/hudi/aws/transaction/lock/DynamoDBBasedImplicitPartitionKeyLockProvider.java`, with configuration in `HoodieLockConfig`. Closing as done. Worth resolving JIRA HUDI-8964 to match. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
