Check for expired lock on first iteration rather than waiting for LEASE_DURATION milliseconds about amazon-dynamodb-lock-client HOT 3 CLOSED

I also find this logic as a bit odd: we don't check existing lock status on the first iteration and we may not pass this condition:

if (LockClientUtils.INSTANCE.millisecondTime() - currentTimeMillis > millisecondsToWait) {
          throw new LockNotGrantedException("Didn't acquire lock after sleeping for " + (LockClientUtils.INSTANCE.millisecondTime() - currentTimeMillis) + " milliseconds");
}

To go to the Thread.sleep(refreshPeriodInMilliseconds); and to the second iteration.
The millisecondsToWait might be small enough and DynamoDB request might be long enough do not let us to overcome that condition.
Therefore it would be great to check an expiration status on existing lock even from the first iteration. We definitely might even not need extra iteration and that unnecessary sleep in between.

Also the current logic doesn't meet boolean tryLock(long time, TimeUnit unit) throws InterruptedException; contract.
I may agree about some timeout approximation during request to the DB and back, but there is definitely no any reason for me to wait for the lock more than tryLock() requests from me.

Originally I did a mistake like:

long timeToWaitForLock = System.currentTimeMillis() - start + TimeUnit.MILLISECONDS.convert(time, unit) - DynamoDbLockRegistry.this.leaseDuration;

this.acquireLockOptionsBuilder
			.withAdditionalTimeToWaitForLock(timeToWaitForLock)
			.withRefreshPeriod(0);

I'm really not interested to wait for the leaseDuration (remember: tryLock() contract ?), so i decided to minus it, but I missed the fact that you don't check status on the first iteration, therefore I failed to meet a condition for the second iteration.

Anyway, independently of my misinterpretation, there is that flaw, when we always fail with the condition because a millisecondsToWait is so small in comparison with the request time, that we never know an existing lock state.

Thanks

from amazon-dynamodb-lock-client.

Yeah, I don't get this either. I wound up having to write my own locking library because this issue prevents usage in Lambda where the lease duration is a significant percentage of the Lambda timeout.

from amazon-dynamodb-lock-client.

@jazir1979 @artembilan @softwareengineerprogrammer This issue is related and may be identical to #12 . Stay tuned, there will be an update to #12 very soon.

from amazon-dynamodb-lock-client.