docs: fix stale lock provider default value in concurrency_control page

[Joy-2000]

Describe the issue this Pull Request addresses

The config table in concurrency_control.md documented the default value of hoodie.write.lock.provider as ZookeeperBasedLockProvider (Optional). This became stale after the code default changed twice and never got updated, so the docs have been misleading users since the 1.0.0 release.

This PR aligns the tables with the actual code default in HoodieLockConfig.LOCK_PROVIDER_CLASS_NAME and with the auto-generated configurations.md.

Summary and Changelog

Updated the config-table cell for hoodie.write.lock.provider in 6 files:

File	Before	After
website/docs/concurrency_control.md	ZookeeperBasedLockProvider (Optional)	N/A **(Required)**
website/versioned_docs/version-1.0.0/concurrency_control.md	ZookeeperBasedLockProvider (Optional)	InProcessLockProvider (Optional)
website/versioned_docs/version-1.0.1/concurrency_control.md	ZookeeperBasedLockProvider (Optional)	N/A **(Required)**
website/versioned_docs/version-1.0.2/concurrency_control.md	ZookeeperBasedLockProvider (Optional)	N/A **(Required)**
website/versioned_docs/version-1.1.1/concurrency_control.md	ZookeeperBasedLockProvider (Optional)	N/A **(Required)**
website/versioned_docs/version-1.2.0/concurrency_control.md	ZookeeperBasedLockProvider (Optional)	N/A **(Required)**

• 1.0.0 → InProcessLockProvider (Optional), matching the code default in those releases (and the auto-generated configurations.md).
• 1.0.1 and later (incl. current docs) → N/A **(Required)**, since there is no default and the provider must be set explicitly.

Impact

none

Risk Level

none

Documentation Update

concurrency_control page on hudi website

Contributor's checklist

• Read through contributor's guide
• Enough context is provided in the sections above
• Adequate tests were added if applicable

[hudi-agent]

⚠️ 🤖 This review was generated by an AI agent and may contain mistakes. Please verify any suggestions before applying.

test

[voonhous]

Docs-only change on asf-site: updates the hoodie.write.lock.provider default cell in the hand-maintained "Enabling Multi Writing" config table across 6 concurrency_control.md files. One line changed per file, nothing else. Thanks for picking this up, the row has been stale since the 1.0.x line.

I checked HoodieLockConfig.LOCK_PROVIDER_CLASS_NAME at each release tag:

Version	Code default at the release tag	PR sets	Verdict
1.0.0	InProcessLockProvider	InProcessLockProvider (Optional)	correct
1.0.1	noDefaultValue()	InProcessLockProvider (Optional)	wrong
1.0.2	noDefaultValue()	N/A **(Required)**	correct
1.1.1	noDefaultValue()	N/A **(Required)**	correct
1.2.0	noDefaultValue()	N/A **(Required)**	correct
master (website/docs)	noDefaultValue()	N/A **(Required)**	correct

Five of the six are right. The 1.0.1 one needs a fix, details inline.

What the PR gets right

• Formatting matches the convention already used on the same page: N/A **(Required)** is what the ZooKeeper, Hive-metastore and DynamoDB tables use for no-default configs.
• Column padding is preserved, so raw-markdown alignment is unchanged. Only column 2 differs; the description column is byte-identical on all 6 lines.
• Scope looks right. The same stale row also exists in version-0.14.0 through version-0.15.1, and the PR correctly leaves those alone: release-0.14.0 really does have .defaultValue(ZookeeperBasedLockProvider.class.getName()). There is no version-1.1.0 under versioned_docs, so all 1.x versions are covered. No prose elsewhere in these pages asserts a lock-provider default.
• asf-site is the right base branch for this.

Optional follow-up, not blocking

versioned_docs/version-1.0.1/configurations.md carries the same wrong value, for the same reason (see the inline note on the 1.0.1 file). Since those are generated snapshots, hand-editing is a committer's call, but it may be worth a JIRA: if that file was never regenerated for 1.0.1, other configs that changed between 1.0.0 and 1.0.1 are probably wrong there too.

Risk / tests

Docs-only, no code paths touched, no tests applicable. Risk is limited to rendering, and the padding check above confirms the table still renders the same.

[voonhous]

This one should be N/A **(Required)**, same as 1.0.2 and later.

The default was removed by 63ad659a672d "[HUDI-8930] Removing default lock provider (#12730)" (2025-01-29), and the earliest release containing that commit is release-1.0.1, not 1.0.2:

$ git tag --contains 63ad659a672d | grep -E '^release-1\.[0-9]+\.[0-9]+$'
release-1.0.1
release-1.0.2

Direct confirmation at the tag:

$ git show release-1.0.1:hudi-client/hudi-client-common/src/main/java/org/apache/hudi/config/HoodieLockConfig.java
  public static final ConfigProperty<String> LOCK_PROVIDER_CLASS_NAME = ConfigProperty
      .key(LOCK_PREFIX + "provider")
      .noDefaultValue()
      .markAdvanced()

There is no withInferFunction on it either, so it really is unset in 1.0.1.

On the justification in the PR description: versioned_docs/version-1.0.1/configurations.md is byte-identical to versioned_docs/version-1.0.0/configurations.md (diff reports no differences), so it was copied at version-cut time and never regenerated for 1.0.1. It is stale for this same config, which means matching it propagates the error instead of fixing it.

With this changed, the cutover line in the description becomes "1.0.1 and later" rather than "1.0.2 and later".

[Joy-2000]

@voonhous you're right, thanks for the correction. I've updated the affected concurrency_control.md files accordingly:

1.0.0 → InProcessLockProvider (Optional), matching the code default in those releases.
1.0.1 and later (including the current docs) → N/A (Required), since the config no longer has a default (noDefaultValue()) and must be set explicitly.

[hudi-agent]

⚠️ 🤖 This review was generated by an AI agent and may contain mistakes. Please verify any suggestions before applying.

Thanks for the docs update! These changes correct the stale hoodie.write.lock.provider default across the concurrency_control pages, and I verified them against HoodieLockConfig and git history: 1.0.0 legitimately keeps InProcessLockProvider, while 1.0.2/1.1.1/1.2.0/current correctly become N/A **(Required)** (the code uses .noDefaultValue()). The only outstanding concern is the already-flagged 1.0.1 file, which should be N/A **(Required)** since commit 63ad659 removed the default in 1.0.1 — no need to re-litigate here. Please have a Hudi committer or PMC member (e.g. @yihua) give it a final look.

cc @yihua