Issue Details (XML | Word | Printable)

Key: DBCP-238
Type: Bug Bug
Status: Resolved Resolved
Resolution: Won't Fix
Priority: Major Major
Assignee: Unassigned
Reporter: Benoit Lafontaine
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
Commons Dbcp

The BasicDataSource setLoginTimeout and getLoginTimeout are not supported

Created: 27/Aug/07 03:29 PM   Updated: 25/Mar/09 12:59 PM
Return to search
Component/s: None
Affects Version/s: 1.2.2
Fix Version/s: 1.3

Time Tracking:
Not Specified

File Attachments:
  Size
Text File Licensed for inclusion in ASF works DBCP-238.patch 2007-08-27 03:40 PM Benoit Lafontaine 48 kB
Issue Links:
Reference
 

Resolution Date: 25/Mar/09 12:59 PM


 Description  « Hide
Methods setLoginTimeout() and getLoginTimeout() are not supported.

 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Benoit Lafontaine added a comment - 27/Aug/07 03:32 PM
The DBCP-218 is fixed by adding a Javadoc comment.

Benoit Lafontaine added a comment - 27/Aug/07 03:40 PM
This patch try to add the loginTimeout feature.
This is made by creating another thread that will call the _driver.connect(_connectUri, _props);
The main thread will wait for it by using the Thread.join(timeout) method.
If the join method returns by timeout and the connect didn't finished, then the main method will throw an SQLException "timeout".

Anyway, for the moment, the second Thread will not be stopped, even if the Thread.interrupted() method is called.


Phil Steitz added a comment - 21/Mar/09 03:30 PM
I see four alternatives here. If others have better ideas, please chime in.

1) Apply cleaned up version of the patch.
2) Add a loginTimeout property to BDS, DCF and pass it to the driver as a property.
3) View this as synonymous with maxWait (modulo unit difference)
4) WONTFIX

I don't like the idea of spawning a thread in 1), 2) can already be accomplished in the connect string, 3) is redundant, so unless someone has a better idea, I think we should close as WONTFIX.


Mark Thomas added a comment - 25/Mar/09 12:59 PM
I agree with Phil's analysis. Therefore, resolving as WONTFIX.