Hard limit for DynamicPool

Developer
Oct 12, 2012 at 9:57 AM

What do you think about having an optional hard limit for a number of resources created and managed by the DynamicPool? Reason for this could be to avoid excessive creation of expensive pooled resources like DB, HTTP sessions, etc. causes by a bug or misusing of the pool. External resource can be put out of service in situations like this one.

Coordinator
Oct 12, 2012 at 12:26 PM

Sounds interesting. I need some details on how will the feature work. What exactly are we putting the constraint on: on the # of resources currently pooled + # of resources currently given away?

How will the pool behave when the limit is reached? My take on stuff like this is: exception is appropriate for all methods unable to do their jobs (e.g. PoolExhaustedException).

That said, I'm going to reiterate that question I sent you via email: have you tried the implicit pooling that comes with database connections yet? Does it suit your needs? I'm pretty sure there can be some implicit pooling in place in Windows with TCP-connections as well... Have you investigated that? It's important to do that first, before using stuff like PoolKit, in my opinion.

Looking forward to hearing from you.

Developer
Oct 15, 2012 at 9:56 AM
Sounds interesting. I need some details on how will the feature work. What exactly are we putting the constraint on: on the # of resources currently pooled + # of resources currently given away?

From perspective of using the pool for storing expensive resources, I would say limiting the number of lent with a ready to lend resources makes sense. For instance, when the hard limit is set to 5 and 2 resources have been lent, the pool can have only 3 resources ready to be lent and should not instantiate objects beyond this limit.

How will the pool behave when the limit is reached? My take on stuff like this is: exception is appropriate for all methods unable to do their jobs (e.g. PoolExhaustedException).

 What about having this behavior configurable? It might make a sense to do one of these depending on situation:

  • As you suggested, throwing an exception.
  • Returning null.
  • Blocking for a certain time span.

Have you tried the implicit pooling that comes with database connections yet? Does it suit your needs?

Thanks for pointing this out, I didn't know about it. Yes, I am going to use it rather than PoolKit in this case as a DB pooling is supported out of box.

I'm pretty sure there can be some implicit pooling in place in Windows with TCP-connections as well

 I have to pool FTP client objects provides by a 3rd party library which implement IDisposable. I am afraid a TCP pool cannot be really used in this situation.

Thanks for your suggestions.

Coordinator
Oct 15, 2012 at 3:04 PM
Edited Oct 15, 2012 at 3:04 PM

From perspective of using the pool for storing expensive resources, I would say limiting the number of lent with a ready to lend resources makes sense. For instance, when the hard limit is set to 5 and 2 resources have been lent, the pool can have only 3 resources ready to be lent and should not instantiate objects beyond this limit.

OK, sounds nice, makes sense, too. We can do that.

What about having this behavior configurable? It might make a sense to do one of these depending on situation:

  • As you suggested, throwing an exception.
  • Returning null.
  • Blocking for a certain time span.

I would say I'm strongly against nulls. This is increasing cyclomatic complexity for no good reason. Exceptions and blocking are both fine. I would stick to exceptions in the first version as they are easier to do.

Thanks for your suggestions.

You're welcome.

Do you have any other ideas? Is this your highest-priority request?

Developer
Oct 19, 2012 at 10:16 AM
Do you have any other ideas? Is this your highest-priority request?

I would not say it is my highest-priority request as it sounds a bit harsh ;) I am going to think how it could be implemented and get back to you with ideas.

Coordinator
Oct 19, 2012 at 10:51 AM

Very well. I'm available for discussions of all kinds, should you need any.