[
https://issues.apache.org/jira/browse/HUDI-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen updated HUDI-6930:
-----------------------------
Description:
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)
> Eliminate the shouldLock flag for TimeGenerator
> -----------------------------------------------
>
> Key: HUDI-6930
> URL: https://issues.apache.org/jira/browse/HUDI-6930
> Project: Apache Hudi
> Issue Type: Improvement
> Components: core
> Reporter: Danny Chen
> Priority: Major
> 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)
