[
https://issues.apache.org/jira/browse/HUDI-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883645#comment-17883645
]
Danny Chen commented on HUDI-6930:
----------------------------------
Like described in the context, there is no good sulution now and it is not a
blocker because TimeGenerator is a developer API, move it to phase2 and would
rethink it in the future.
> Eliminate the shouldLock flag for TimeGenerator(phase2)
> -------------------------------------------------------
>
> Key: HUDI-6930
> URL: https://issues.apache.org/jira/browse/HUDI-6930
> Project: Apache Hudi
> Issue Type: Improvement
> Components: core
> Reporter: Danny Chen
> Assignee: Danny Chen
> Priority: Critical
> Fix For: 1.0.0
>
>
> In HUDI-1623, we introduced the TimeGenerator, but left a shouldLock flag on
> the interfaces which increases the complexity for maintainance.
> Basically, we need to make the lock provider as reentrant to alleviate the
> situration.
> Several ideas here (aborted):
> 1. introduces the isLocked interface on the LockProvider and uses that to
> decide on whether we need a separate lock for the TimeGenerator (disapproved
> because this method has no guarantee of atomicity)
> 2. create temporary marker files for passing the flag (does not midiate the
> complexity, the caller stills needs to care about whether we should add lock
> or not)
> 3. set the shouldLock flag into the TimeGenerator instance (same as 2, does
> not really soves the problem)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
