[Feature Request] Soft Unlock #92
Description
In a high throughput batch processing system with a high success rate, it is beneficial to NOT unlock after processing a request successfully (successfully is the keyword here) since no process will ever need to let alone try to acquire the lock again, since the work is completed. However, if you do not call unlock, the heap will eventually fill up within the JVM since locks are only removed from the ConcurrentHashMap after unlock is called.
Proposal: add the ability for the user to remove locks from the ConcurrentHashMap (named locks) without making a call to ddb to delete the lock, in order to be frugal on unnecessary network calls to ddb. The implementation may be very similar to the current unlock method, just without the network calls to ddb. This could be passed as an option.
I would be happy to contribute this if in advance you informed me the proposal is accepted.