[core] Rewrite oss tryToWriteAtomic using atomic putObject API (#8226)#8228
Open
MaxLinyun wants to merge 1 commit into
Open
[core] Rewrite oss tryToWriteAtomic using atomic putObject API (#8226)#8228MaxLinyun wants to merge 1 commit into
MaxLinyun wants to merge 1 commit into
Conversation
MaxLinyun
force-pushed
the
fix/make-tryToWriteAtomic-atomic-in-oss
branch
from
7feed20 to
18e4e42
Compare
…of the OSS SDK (apache#8226) Paimon's existing OSSFileIO inherits from HadoopCompliantFileIO, with file operations implemented underneath via Hadoop's AliyunOSSFileSystem. In object storage scenarios, the default implementation of tryToWriteAtomic follows the pattern of 'writing a temporary file followed by renaming'. However, renaming on OSS is essentially a copy-then-delete process and not an atomic operation. Rewrite the implementation of tryToWriteAtomic, and directly call the conditional write API (put-if-absent) of the OSS SDK, so as to implement the atomic 'write if not exists' semantics without relying on external locks.
MaxLinyun
force-pushed
the
fix/make-tryToWriteAtomic-atomic-in-oss
branch
from
18e4e42 to
a9c77ce
Compare
Author
|
@JingsongLi Hi, could you help review this PR? |
JingsongLi
reviewed
Jun 16, 2026
|
|
||
| ObjectMetadata metadata = new ObjectMetadata(); | ||
| metadata.setContentLength(bytes.length); | ||
| metadata.setHeader("x-oss-forbid-overwrite", "true"); |
Contributor
There was a problem hiding this comment.
The direct SDK upload no longer carries fs.oss.server-side-encryption-algorithm into ObjectMetadata. The Hadoop OSS write path that this replaces sets ObjectMetadata#setServerSideEncryption before putObject; with catalogs configured for OSS SSE this can either violate bucket policies that require encrypted uploads or create unencrypted metadata/version files. Could we set the same SSE header from the configured Hadoop options/store before calling putObject?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Purpose
closes #8226
Paimon's existing OSSFileIO inherits from HadoopCompliantFileIO, with file operations implemented underneath via Hadoop's AliyunOSSFileSystem. In object storage scenarios, the default implementation of tryToWriteAtomic follows the pattern of 'writing a temporary file followed by renaming'. However, renaming on OSS is essentially a copy-then-delete process and not an atomic operation.
Rewrite the implementation of tryToWriteAtomic, and directly call the conditional write API (put-if-absent) of the OSS SDK, so as to implement the atomic 'write if not exists' semantics without relying on external locks.
Tests
Since I cannot put oss ak/sk to test case, I don't know how to write test case.