OK, so short of waiting for this to fail again, how might I go about
testing this works? Should I see if the database folks can kill the JDBC
connections manually?

Shapira, Yoav wrote:

Hi,
The DBCP parameters are for DBCP.  DBCP won't magically set various
properties on your IBM driver, so if you want those set you have to do
it yourself.

If you use IBM's pooling, as opposed to IBM's driver with DBCP's
pooling, you can set those properties in your Tomcat xml configuration,
as long as the factory provided by IBM supports that approach.

Yoav Shapira http://www.yoavshapira.com




-----Original Message-----
From: Ruth, Brice [mailto:[EMAIL PROTECTED]
Sent: Monday, December 06, 2004 3:31 PM
To: Tomcat Users List
Subject: Re: DBCP/JNDI/Realms

Follow-up question. Should I or should I not use the ConnectionPool
implementation provided by IBM in their JDBC driver? And if I should,


do


the parameters provided by DBCP still apply? I have to admit, I'm a bit
fuzzy on what role which component is playing in this game!

Thanks!!

Shapira, Yoav wrote:



Hi,
DBCP will NOT gracefully recover by itself.  You need to configure it
according to your desired behavior.  Specifically, check out the
testOnBorrow, testOnReturn, and testWhileIdle properties at
http://jakarta.apache.org/commons/dbcp/configuration.html.

Yoav Shapira http://www.yoavshapira.com






-----Original Message-----
From: Ruth, Brice [mailto:[EMAIL PROTECTED]
Sent: Monday, December 06, 2004 11:32 AM
To: Tomcat Users List
Subject: DBCP/JNDI/Realms

Good morning!

I've been running into an intermittent problem with my database
connections for authentication. It appears that periodically, the
iSeries (DB2/400) that I connect to terminates all incoming ODBC/JDBC
connections (one a week, apparently). What happens in my application


is


that users can no longer login after the connections have been


dropped.


The connection pool apparently doesn't try to re-initiate the
connections after they've been dropped.

I see an exception in my logs regarding the connection being reset,




then




I see an exception relating to the pool being exhausted. I'm not
entirely sure what the root cause of the problem here is - in theory,
DBCP should recover gracefully when a connection is reset/dropped,




right?




Here's the initial exception:
java.sql.SQLException: Communication link failure.(Connection was
dropped unexpectedly.)
     at




com.ibm.as400.access.JDError.throwSQLException(JDError.java:365)




at
com.ibm.as400.access.AS400JDBCConnection.send(AS400JDBCConnection.jav


a(




Comp




iled
Code))
at
com.ibm.as400.access.AS400JDBCConnection.send(AS400JDBCConnection.jav


a(




Inli




ned
Compiled Code))
at
com.ibm.as400.access.AS400JDBCStatement.syncRPB(AS400JDBCStatement.ja


va




(Com




piled
Code))
at
com.ibm.as400.access.AS400JDBCStatement.commonPrepare(AS400JDBCStatem


en




t.ja




va(Compiled
Code))
at
com.ibm.as400.access.AS400JDBCPreparedStatement.<init>(AS400JDBCPrepa


re




dSta




tement.java(Compiled
Code))
at
com.ibm.as400.access.AS400JDBCConnection.prepareStatement(AS400JDBCCo


nn




ecti




on.java(Compiled
Code))
at
com.ibm.as400.access.AS400JDBCConnection.prepareStatement(AS400JDBCCo


nn




ecti




on.java(Compiled
Code))
at
org.apache.commons.dbcp.DelegatingConnection.prepareStatement(Delegat


in




gCon




nection.java(Compiled
Code))
at
org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.


pr




epar




eStatement(PoolingDataSource.java(Compiled
Code))
at
org.apache.catalina.realm.DataSourceRealm.credentials(DataSourceRealm


.j




ava:




460)
[snip]

Here's the next one:
2004-12-06 04:39:21 DataSourceRealm[]: Exception performing




authentication




org.apache.commons.dbcp.SQLNestedException: Cannot get a connection,
pool exhausted
at
org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSo


ur




ce.j




ava(Compiled
Code))
at
org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource


.j




ava(




Compiled
Code))
at
org.apache.catalina.realm.DataSourceRealm.open(DataSourceRealm.java:4


38




)




at
org.apache.catalina.realm.DataSourceRealm.authenticate(DataSourceReal


m.




java




:277)
[snip]

So, what I've done now to see if it helps matters any, is specify the
AS400's own connection pool factory in my JNDI definition, like so:

   <parameter>
     <name>factory></name>

<value>com.ibm.as400.access.AS400JDBCConnectionPoolDataSource</value>
   </parameter>

Both Tomcat's form authentication as well as my application (through
iBATiS) use this JNDI DataSource for connections.

Can anyone shed more light on what the root cause of the problem is
here? Should DBCP gracefully recover?

Regards,
Brice Ruth

--
Brice Ruth, Sr. IT Analyst
Fiskars Brands Inc
http://www.fiskarsbrands.com/


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]






This e-mail, including any attachments, is a confidential business


communication, and may contain information that is confidential,
proprietary and/or privileged. This e-mail is intended only for the
individual(s) to whom it is addressed, and may not be saved, copied,
printed, disclosed or used by anyone else. If you are not the(an)


intended


recipient, please immediately delete this e-mail from your computer


system


and notify the sender. Thank you.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






--
Brice Ruth, Sr. IT Analyst
Fiskars Brands Inc
http://www.fiskarsbrands.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






This e-mail, including any attachments, is a confidential business 
communication, and may contain information that is confidential, proprietary 
and/or privileged.  This e-mail is intended only for the individual(s) to whom 
it is addressed, and may not be saved, copied, printed, disclosed or used by 
anyone else.  If you are not the(an) intended recipient, please immediately 
delete this e-mail from your computer system and notify the sender.  Thank you.


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]






--
Brice Ruth, Sr. IT Analyst
Fiskars Brands Inc
http://www.fiskarsbrands.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to