Add independent lock

[liran2000]

Description

Add a lock class, not depends on leader election.

Usage high level guideline:

try {
  lock.lock(timeout); // blocking
  doSomeAction();
} finally {
  lock.unlock();
}

Use cases

Actions which require distributed lock.

Solution suggestion

implementation details - high level

• lock:
  • try to creates a lease.
  • if already exists, wait and try again until created, or timeout reached.
• unlock:
  • delete the lease.

Note that I have this implementation ready, so if confirmed, I can try opening a PR for it at extended module.
Would appreciate feedback on proceeding with it.

[brendandburns]

What is the purpose of this class? We have several implementations of Lock already:

https://github.com/kubernetes-client/java/blob/master/extended/src/main/java/io/kubernetes/client/extended/leaderelection/resourcelock/LeaseLock.java

[liran2000]

Actions which require a distributed lock. How can lock/unlock usage be achieved with existing lock ?
Keep in mind this functionality commonly needed without leader election.

try {
  lock.lock(timeout); // blocking
  doSomeAction();
} finally {
  lock.unlock();
}

[brendandburns]

Is it that you want to be able to unlock()? If that is the case, I'd prefer that you added that to the existing leader election implementation vs adding a completely new implementation of locking/leader election.

There's not much difference between locking and leader election (except perhaps the unlock part) so I'd prefer to extend the existing implementations.

[liran2000]

Existing LeaseLock implements io.kubernetes.client.extended.leaderelection.Lock, which is "strictly for use by the leaderelection code". Adding to it can feel like abuse.
I am thinking of implementing java.util.concurrent.locks.Lock, as encountered a need for it, for common usage.
What do you think ?

Lock lock = ...;
 if (lock.tryLock()) {
   try {
     // manipulate protected state
   } finally {
     lock.unlock();
   }
 } else {
   // perform alternative actions
 }

[brendandburns]

I think it's definitely fine to implement java.util.concurrent.locks.Lock but I believe that you can implement that using the LeaderElector class, you don't have to implement the lock acquire/retain/release code yourself.

That code is tricky to get right and we're better off focusing on a single implementation.