More lib specific lock prefix

[mvorisek]

No description provided.

[willemstuursma]

Sorry, this cannot be changed.

When deploying a version of this library the new version will not respect existing locks that are held (that were acquired by the version that does not have this change).

[mvorisek]

@willemstuursma good point, but the original prefix can not be used in some enviroments like we have

Until now, we used a fork of this lib, but all offered all customizations as a PRs. If we can not change this, I will still have to maintain that fork... :(

Is this possible to change and release a new major version?

[willemstuursma]

Did you consider using a dedicated redis database for locking then?

[mvorisek]

We have only one DB per deploy.

[mvorisek]

@willemstuursma please reconsider merging this PR

[willemstuursma]

We can do a PR where the lock name or prefix is configured in a protected function (which can be overridden) or a constructor argument.

For more info on Redis databases (which are a way of namespacing as well) see https://www.mikeperham.com/2015/09/24/storing-data-with-redis/#:~:text=Out%20of%20the%20box%2C%20every,conf).

A single server supports 16 databases (0-15).