Also, if you are doing 100 million per day, then with a bit of peak to
valley ratio, you are doing 5000 per second. That is pushing limits. If
your ZK has other loads or is on substandard hardware somehow.

If you are storing things in a database, don't you have an create or fail
operation (AKA INSERT in SQL)? Or on file systems, can't you use *O_CREAT*?



On Thu, Feb 6, 2020 at 4:46 AM Jordan Zimmerman <[email protected]>
wrote:

> Rajat - I don't understand what you're proposing here. Are all entities
> contending for the same lock? It's not possible to have multiple locks
> under 1 ZNode. The lock recipes that Curator (or any ZK app) uses requires
> a unique path for each lock. In any event, If it's all the same lock that
> each entity is contending for then it's fine - that would be the standard
> lock recipe. Maybe I'm missing something?
>
> -Jordan
>
> > On Feb 5, 2020, at 1:21 AM, Rajat Gangwar <[email protected]>
> wrote:
> >
> > Hi Jordan,
> >
> > Planning to have 1 persistent node for the application, say
> > "/entity_locks/". And then all entities will be trying to create
> ephemeral
> > nodes under this parent node.
> >
> > We will be creating 100 million unique entities in a given day. So each
> > unique entity will try to take the lock before persisting to data-store.
> So
> > if ZK will fail to create ephemeral node if it already exists under same
> > parent node, then we can go with this simple implementation.
> >
> > Unless there are some corner cases where this might not work ?
> >
> > Thanks,
> > Rajat
> >
> > On Tue, Feb 4, 2020 at 8:28 PM Jordan Zimmerman <
> [email protected]>
> > wrote:
> >
> >>> can I implement a lock recipe which just
> >>> tries to create ephemeral node without any persistent nodes.
> >>
> >> Ephemeral nodes cannot have any children. Unless you create your lock at
> >> the root ("/") you'd need some parent persistent node. Is this a big
> >> problem for you? Unless you have 1000s of unique lock paths there
> shouldn't
> >> be any problem with persistent parent node.
> >>
> >> -Jordan
>
>

Reply via email to