You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/04/06 16:04:27 UTC
JdbcDataSource Issue Resolved
Thanks to Giacomo, an issue was brought to my attention:
"What if the DB server severs the connection?". Until
now, the bad connection was still kept in the pool.
Obviously this is wrong, so now the JdbcDataSource will
check the connection to see if it is closed (con.isClosed()),
and if so it will destroy the bad connection object and
create a new connection to replace it.
The only problem is if the DB Server is down, the pool will
shrink to zero connections because new connections cannot
be made. The JdbcConnectionPool is designed to have exactly
a certain number of connections, and does not check to see if
it has changed size.
That will be the next step, but we will see how this works.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: JdbcDataSource Issue Resolved
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
>
> Thanks to Giacomo, an issue was brought to my attention:
> "What if the DB server severs the connection?". Until
> now, the bad connection was still kept in the pool.
> Obviously this is wrong, so now the JdbcDataSource will
> check the connection to see if it is closed (con.isClosed()),
> and if so it will destroy the bad connection object and
> create a new connection to replace it.
>
> The only problem is if the DB Server is down, the pool will
> shrink to zero connections because new connections cannot
> be made. The JdbcConnectionPool is designed to have exactly
> a certain number of connections, and does not check to see if
> it has changed size.
>
> That will be the next step, but we will see how this works.
This last issue is resolved. For every get() when the ready
connections are empty, it checks to see if the maximum number
of connections have been created--if not you will get a new
one.
This way if your Database server is down for 5 minutes and
you had 10 requests that required DB access (assuming 10
connections in your pool), you won't be SOL when the DB
server comes back up.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: JdbcDataSource Issue Resolved
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
>
> Thanks to Giacomo, an issue was brought to my attention:
> "What if the DB server severs the connection?". Until
> now, the bad connection was still kept in the pool.
> Obviously this is wrong, so now the JdbcDataSource will
> check the connection to see if it is closed (con.isClosed()),
> and if so it will destroy the bad connection object and
> create a new connection to replace it.
>
> The only problem is if the DB Server is down, the pool will
> shrink to zero connections because new connections cannot
> be made. The JdbcConnectionPool is designed to have exactly
> a certain number of connections, and does not check to see if
> it has changed size.
>
> That will be the next step, but we will see how this works.
This last issue is resolved. For every get() when the ready
connections are empty, it checks to see if the maximum number
of connections have been created--if not you will get a new
one.
This way if your Database server is down for 5 minutes and
you had 10 requests that required DB access (assuming 10
connections in your pool), you won't be SOL when the DB
server comes back up.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org