You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@flink.apache.org by aitozi <gj...@gmail.com> on 2018/08/14 07:19:59 UTC

A litte doubt about the usage of checkpointLock

Hi, community

I see the checkpointLock is used in StreamTask to ensure that we don't have
concurrent method calls that void consistent checkpoints.

As i known, it is used in the data consume , state interactive and the
timerService, But I am doubt that, if an application don't enable the
checkpoint, it still have to deal with the checkpointLock. Is it necessary ? 



--
Sent from: http://apache-flink-user-mailing-list-archive.2336050.n4.nabble.com/

Re: A litte doubt about the usage of checkpointLock

Posted by Andrey Zagrebin <an...@data-artisans.com>.
Hi,

there are at least 3 main players which use the lock to sync state access between each other:
thread processing records in user code, checkpointing thread and processing timers callback thread.

I would still recommend to follow the contract and use the lock where required (e.g. custom source)
because whether it is needed or not eventually depends a lot on internal implementation details which might change. If there is no contention, it will be optimised by JVM and should not degrade performance too much.

Except custom sources as documented, application code is usually not required to deal with the lock in Flink API at all, e.g. in user processing functions.

Cheers,
Andrey

> On 14 Aug 2018, at 09:19, aitozi <gj...@gmail.com> wrote:
> 
> Hi, community
> 
> I see the checkpointLock is used in StreamTask to ensure that we don't have
> concurrent method calls that void consistent checkpoints.
> 
> As i known, it is used in the data consume , state interactive and the
> timerService, But I am doubt that, if an application don't enable the
> checkpoint, it still have to deal with the checkpointLock. Is it necessary ? 
> 
> 
> 
> --
> Sent from: http://apache-flink-user-mailing-list-archive.2336050.n4.nabble.com/