[ http://issues.apache.org/jira/browse/DBCP-163?page=all ]
Phil Steitz updated DBCP-163:
-----------------------------
Bugzilla Id: (was: 30391)
Fix Version: 1.3
> [dbcp] Use setQueryTimeout in combination with validationQuery to recover
> from network problems
> -----------------------------------------------------------------------------------------------
>
> Key: DBCP-163
> URL: http://issues.apache.org/jira/browse/DBCP-163
> Project: Commons Dbcp
> Type: Improvement
> Versions: 1.1 Final
> Environment: Operating System: Linux
> Platform: Other
> Reporter: cryptic
> Priority: Minor
> Fix For: 1.3
>
> When the network connection between tomcat 4.1.29 and database (experienced
> with
> sybase ASE 12.5) is lost, the 'Connection' hangs indefinitely.
> It hangs in the line of code "con = DatasourceObject.getConnection();"
> None of the other options in the connection pooling stuff - add info: used
> SharedPoolDatasourceFactory in dbcp - like maxWait / validationQuery
> /removeAbandoned/ removeAbandonedTimeout etc doesnt timeout the connection.
> Analysis: When the network connection to the database is fine (normal
> scenario)-
> the dbcp gets a connection from the datasource (connection pool)- sets three
> params - autocommit, readonly and isolation level for the connection object
> and
> returns this improved connection object to the calling class.
> Now say the network connection is lost, and the unaware application requests
> for
> a connection from the pool, gets the connection object and then tries to set
> the
> first of three params (autocommit- mentioned above) where it hangs.
> None of the timeout params work in this scenario. Setting a validationQuery
> tries its validation only after getting the connection object which never
> happens.
> Soln(possibility): after getting the raw connection object - run a validation
> query (or any call to database)with a stmt.setQueryTimeout() set to say 3-5
> secs
> - or say configurable by user - and then catch the exception (noroutetohost
> exception) to throw it back.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
