cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tagunov Anthony" <atagu...@nnt.ru>
Subject Re: [C2][feature request][Datasource components] get-by-name + no-pooling
Date Mon, 29 Jan 2001 07:46:24 GMT
On Sun, 28 Jan 2001 09:28:31 -0500, Berin Loritsch wrote:

>----- Original Message -----
>From: Tagunov Anthony <atagunov@nnt.ru>
>To: <cocoon-dev@xml.apache.org>
>Sent: Saturday, January 27, 2001 3:33 PM
>Subject: [C2][feature request][Datasource components] get-by-name +
>no-pooling
>
>
>> Hello all!
>> Hello Berin! (I was directed to you to ask this question :-)
>>
>> ASFAIK in C1 database connection pooling gave two features in one
>> bottle:
>>
>> retriving connection properties by name (short, nice, usefull name -
>great!)
>> connection pooling
>>
>> AFAIK similar facilities are being (have been) developed for C2.
>
>They _have_ been developed. for C2.  We have a Cocoon DataSource object
>that allows you to retrieve the connection with one short name.
>
>> Do you think it's reasonable for us to have
>>
>> retriving connection properties by name without connection pooling?
>
>Sure it would be possible.  The J2eeDataSource connection does just that.
>The JdbcDataSource connection could be extended to make a
>FactoryJdbcDataSource
>connection--that simply creates new Connection objects on demand.
>
>> The reasons I want this are the following:
>>
>> - our dbms is unreliable and I feel much more comfortable to reopen the
>connection every time
>
>Really?  What are you using?  

I'm not sure I'm allowed to scould it in the open here..

>(it might make sense to look for an
>alternative that is more
>reliable and possibly cheaper).

It's not my prerrogative..

>> - caching suits our needs fine and we are not bothered with extra time for
>reconnecting
>
>Ok.  Caching of the results would be the responsibility of your code with
>the C2 DataSources

I mean Cocoon caching

>> - last but most important: WE ARE LIMIITED ON DATABASE LICENSES. And we're
>running approx 6 to 8
>> instances of Cocoon+Tomcat a time (to make our sites completely
>independent, and prevent problems in
>> one of them to spread onto others.) So we simply can not afford having our
>PRECIOUS database
>> licences be eat up just by being pooled on all of these 8 instances.

Well, what I mean is that I would like as 0..n connections available
to each instance of servlet runner+cocoon.

But what I really want is that these connection WOULD BE RELEASED right
after I've utilized 'em.

No connections should EVER be kept in reserve.

>You have direct control over the maximum number of connections in a pool.
>If you only wanted to use three simultaneous
>connections in one site and four in another site, you would be able to do
>just that.  The pool has both a maximum and
>a minimum amount of connections.  The maximum is a hard maximum, and the
>getConnection() would fail if an additional
>one was needed--I need to look at waiting for one to free up though.  The
>minimum is a soft minimum meaning that at least
>the minimum number of connections will be held in reserve unless we would
>have more than the hard maximum.

So, does setting this to 0 guarantee that NO SPARE CONNECTIONS MAY EVER
BE KEPT IN RESERVE or not?

You write: "at least" the "soft minimum" nuber of connections will be kept in reserve.
Does it mean that more then that may be kept? If so, it's not exactly what I want.

>


>
>Another answer to your question above is to set the minimum connections to 0
>and the maximum to 1--that way you are
>guaranteed only 1 connection is used per instance of Cocoon.
>
>> AFAI Understand, if this feature would be (is) supported by datasource
>components,
>> it might find it's way into esql.xsl
>
>It already has.  esql.xsl has two ways of specifying connections:
>
><esql:dbpool>datasource name</esql:dbpool>
>
>and the normal connection property settings.  The dbpool property uses the
>C2 connections.
>
>>
>> Best regards,
>>  Tagunov Anthony
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>




Mime
View raw message