maxStrict not available for ResourceLimitingJdbcDataSource?

[Mark Woon <mo...@SMI.Stanford.EDU>]

Is there a reason why the ResourceLimitingJdbcDatasource doesn't allow
maxStrict parameter to the ResourceLimitingPool to be configured?
Without it, the only difference between the
ResourceLimitingJdbcDataSource and the JdbcDataSource is that the former
will allow you to block if max connections has been met.

I've attached a patch that allows maxStrict to be customized.  I've also
added a bit of documentation on the auto-commit option.

-Mark

Re: maxStrict not available for ResourceLimitingJdbcDataSource?

[Mark Woon <mo...@SMI.Stanford.EDU>]

Leif Mortenson wrote:

> In a way, max-strict=false takes the
> safety off and puts your DB at risk.   MySQL will crash in short order
> under these circumstances for example.
>
> For this reason, I modified your patch to explain these issues.

Ah.  Thanks Leif.  I guess I didn't really think it through.

-Mark


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: maxStrict not available for ResourceLimitingJdbcDataSource?

[Berin Loritsch <bl...@apache.org>]

Leif Mortenson wrote:
> Applied Thanks!
> 
> Mark Woon wrote:
> 
>> Is there a reason why the ResourceLimitingJdbcDatasource doesn't allow
>> maxStrict parameter to the ResourceLimitingPool to be configured?
>> Without it, the only difference between the
>> ResourceLimitingJdbcDataSource and the JdbcDataSource is that the former
>> will allow you to block if max connections has been met.
>>
> I guess there is no reason not to allow the max-strict attribute to be 
> set, but I can not imagine
> where you would want to use it.  Database connections will always have 
> an upper limit on the number
> of connections that you can open to the database.  The JdbcDataSource 
> class will open up to max
> and keep them open.  In that case, it would be useful.  But the 
> ResourceLimitingJdbcDataSource
> supports pool trimming so the size will never be larger than is really 
> needed.  If your application will
> usually only need 3 connections, but you can allow up to 10, then set 
> max=10.  The pool will
> grow if necessary, but will quickly drop back down to 3 when the extra 7 
> are no longer needed.
> If you set max-strict=false, then under very heavy DB loads, your 
> database may crash because your
> app server tries to open up a very large number of connections.  In a 
> way, max-strict=false takes the
> safety off and puts your DB at risk.   MySQL will crash in short order 
> under these circumstances
> for example.
> 
> For this reason, I modified your patch to explain these issues.

Leif, the reason we had a fixed size pool (i.e. max-strict="true") is
for licensing issues.  Companies like Oracle and Informix limit the
number of clients that can be connected at any one time.

The ability to turn it off would work under certain circumstances,
where the licensing issues are not a problem.  As you pointed out with
MySQL, sometimes you either need to restrict it for stability reasons
or slow the connection creation time (who knows maybe something will
be released in the mean time...).

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: maxStrict not available for ResourceLimitingJdbcDataSource?

[Leif Mortenson <le...@silveregg.co.jp>]

Applied Thanks!

Mark Woon wrote:

>Is there a reason why the ResourceLimitingJdbcDatasource doesn't allow
>maxStrict parameter to the ResourceLimitingPool to be configured?
>Without it, the only difference between the
>ResourceLimitingJdbcDataSource and the JdbcDataSource is that the former
>will allow you to block if max connections has been met.
>
I guess there is no reason not to allow the max-strict attribute to be 
set, but I can not imagine
where you would want to use it.  Database connections will always have 
an upper limit on the number
of connections that you can open to the database.  The JdbcDataSource 
class will open up to max
and keep them open.  In that case, it would be useful.  But the 
ResourceLimitingJdbcDataSource
supports pool trimming so the size will never be larger than is really 
needed.  If your application will
usually only need 3 connections, but you can allow up to 10, then set 
max=10.  The pool will
grow if necessary, but will quickly drop back down to 3 when the extra 7 
are no longer needed.
If you set max-strict=false, then under very heavy DB loads, your 
database may crash because your
app server tries to open up a very large number of connections.  In a 
way, max-strict=false takes the
safety off and puts your DB at risk.   MySQL will crash in short order 
under these circumstances
for example.

For this reason, I modified your patch to explain these issues.

Thanks
Leif



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>