This PR implements tryTakeResource and tryWithResource, which each return immediately if allocating a resource from the pool would block (because the pool is exhausted).
This is useful for implementing network clients which need to deal with many pools of connections to (potentially) many servers, such as distributed databases. In these cases, it is often desirable to employ some sort of retry strategy, or to balance operations across hosts. Thereby, it is also desirable to leave these decisions to the user, as opposed to implementing some magic behavior in the pool itself.
An alternative solution could be to provide introspection into the current pool usage. This, however, has the disadvantage of not being an atomic operation. Ie. a takeResource may still block, even though we've checked before that we didn't exceed maxResources.
Implementation note: there seemingly is some code duplication, but I figured I'd end up with quite some unnecessary boxing/unboxing otherwise.
This PR implements
tryTakeResource
andtryWithResource
, which each return immediately if allocating a resource from the pool would block (because the pool is exhausted).This is useful for implementing network clients which need to deal with many pools of connections to (potentially) many servers, such as distributed databases. In these cases, it is often desirable to employ some sort of retry strategy, or to balance operations across hosts. Thereby, it is also desirable to leave these decisions to the user, as opposed to implementing some magic behavior in the pool itself.
An alternative solution could be to provide introspection into the current pool usage. This, however, has the disadvantage of not being an atomic operation. Ie. a
takeResource
may still block, even though we've checked before that we didn't exceedmaxResources
.Implementation note: there seemingly is some code duplication, but I figured I'd end up with quite some unnecessary boxing/unboxing otherwise.