[jira] Updated: (DBCP-143) [dbcp] SQLNestedException thrown by server causes client ClassNotFoundException.
[ https://issues.apache.org/jira/browse/DBCP-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom updated DBCP-143: Fix Version/s: (was: 1.3) 1.4 SQLNestedException has been deprecated in 1.3 and will be removed in 1.4 [dbcp] SQLNestedException thrown by server causes client ClassNotFoundException. Key: DBCP-143 URL: https://issues.apache.org/jira/browse/DBCP-143 Project: Commons Dbcp Issue Type: Bug Environment: Operating System: other Platform: Other Reporter: Andreas Krüger Fix For: 1.4 Attachments: DBCP-143.patch This is a GUI client / application server / database server application. On the GUI client side, we see java.lang.ClassNotFoundException: org.apache.commons.dbcp.SQLNestedException. This happens when the database server is down, DBCP cannot connect to the database, and throws a org.apache.commons.dbcp.SQLNestedException. Our application server code sends the java.sql.SQLException it sees to the client via RMI. However, on the client, we have not provided commons-dbcp.jar. And I don't think we should - DBCP is server code. But, when the client does not have SQLNestedException's class file, the attempt to de-serialize it results in the ClassNotFoundException we've been seeing. Even old http://java.sun.com/j2se/1.3/docs/api/java/sql/SQLException.html has the facilities that SQLNestedExcepion offers: It is able to chain another SQLException to itself. So while SQLNestedException clearly causes problems, I don't understand what DBCP gains from it. What would we loose if it were scratched? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (DBCP-194) BasicDataSource.setLogWriter should not do createDataSource
[
https://issues.apache.org/jira/browse/DBCP-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom closed DBCP-194.
---
Resolution: Fixed
Fixed some time ago.
BasicDataSource.setLogWriter should not do createDataSource
---
Key: DBCP-194
URL: https://issues.apache.org/jira/browse/DBCP-194
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.2
Reporter: Kees de Kooter
Fix For: 1.3
Attachments: AbandonedObjectPool.patch
The code for setLogWriter is:
public void setLogWriter(PrintWriter logWriter) throws SQLException {
createDataSource().setLogWriter(logWriter);
this.logWriter = logWriter;
}
This means that before a custom log writer is set a datasource is created.
Any logging happening while creating the datasource is directed to stdout /
stderr.
I think the purpose of setting a log writer is to prevent this, at least that
is what I am trying to achieve.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (DBCP-102) [dbcp] setReadOnly setAutoCommit called too many times
[ https://issues.apache.org/jira/browse/DBCP-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom closed DBCP-102. --- Resolution: Fixed Fixed some time ago. [dbcp] setReadOnly setAutoCommit called too many times Key: DBCP-102 URL: https://issues.apache.org/jira/browse/DBCP-102 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2 Environment: Operating System: other Platform: Sun Reporter: AC Fix For: 1.3 In order to gain some processor time for my application that uses Hibernate, I looked with optimizeIt where it spends time. It seems that for a request on the database (Oracle 9) around 25% (!!?) is spent on getting the connection from the DBCP pool, and this not only the first time!. The methods that provoke this loss of time are connection.setReadOnly and connection.setAutoCommit called inside the method PoolableConnectionFactory.activateObject. Looking to the stack, these calls translate to communication with the Oracle server. The obvious thing to do is to check if read only and autocommit flags are already set to the expected values. (Of course, Oracle could 've done this too, but I hope you'll have a faster response :) ) Thank you very much for you help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (DBCP-212) PoolingDataSource closes physical connections
[ https://issues.apache.org/jira/browse/DBCP-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom closed DBCP-212. --- Resolution: Fixed Fixed some time ago. PoolingDataSource closes physical connections - Key: DBCP-212 URL: https://issues.apache.org/jira/browse/DBCP-212 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.2 Environment: Windows XP, Java 1.5.0_06-b05, Sybase ASE 12.5.4, jConnect 6.0.5 EBF 13862, Commons Pool 1.3 Reporter: Marcos Sanz Fix For: 1.3 Attachments: DBCPtester.java, DBCPtester.java, output.txt By executing the attached program and monitoring the process id of the physical connections at the database server, it is possible to demonstrate that the connections are being actually physically closed and reopened by the application at a very high rate. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (DBCP-97) setAutoCommit(true) when returning connection to the pool
[ https://issues.apache.org/jira/browse/DBCP-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom closed DBCP-97. -- Resolution: Fixed Fixed some time ago. setAutoCommit(true) when returning connection to the pool - Key: DBCP-97 URL: https://issues.apache.org/jira/browse/DBCP-97 Project: Commons Dbcp Issue Type: Bug Affects Versions: Nightly Builds Environment: Operating System: All Platform: All Reporter: Dirk Verbeeck Fix For: 1.3 From the Struts user list: [OT] RE: Stackoverflow after DB inactivity (MySQL reconnect problem) http://www.mail-archive.com/[EMAIL PROTECTED]/msg70196.html Giving a hint to the database driver that you don't need long running transactions makes sense. setAutoCommit(true) should be added to PoolableConnectionFactory.passivateObject -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (DBCP-152) [DBCP] add a socketFactory attribute to BasicDataSource (to allow SSL thread-safe)
[ https://issues.apache.org/jira/browse/DBCP-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom closed DBCP-152. --- Resolution: Won't Fix [DBCP] add a socketFactory attribute to BasicDataSource (to allow SSL thread-safe) Key: DBCP-152 URL: https://issues.apache.org/jira/browse/DBCP-152 Project: Commons Dbcp Issue Type: Improvement Affects Versions: 1.2 Environment: Operating System: All Platform: Other Reporter: Ralf Hauser Priority: Minor Fix For: 1.3 An app that accesses 2 datasources at two different places with different security policies via SSL (different set of permitted ciphers) currently is out of luck (http://lists.mysql.com/java/8689). The basic datasource should be enhanced with String socketFactory = ; and the corresponding getter and setter method, etc. org.apache.commons.dbcp.DriverConnectionFactory.createConnection() could then hand-over this full className via its Properties argument to enable different SSL policies per datasource (so, since the application programmer doesn't have the thread under her control, I guess it should rather be called dataSource-safe). The jdbc driver implementation can then use this to take the appropriate socket factory when creating a connection. See also http://lists.mysql.com/java/8695 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (DBCP-155) [dbcp] allow to set = 6 parameters to do non-global SSL
[ https://issues.apache.org/jira/browse/DBCP-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom closed DBCP-155. --- Resolution: Won't Fix [dbcp] allow to set = 6 parameters to do non-global SSL Key: DBCP-155 URL: https://issues.apache.org/jira/browse/DBCP-155 Project: Commons Dbcp Issue Type: Improvement Environment: Operating System: All Platform: Other Reporter: Ralf Hauser Priority: Minor Fix For: 1.3 to work with http://dev.mysql.com/doc/refman/5.1/en/cj-using-ssl.html, it should be possible to call DriverManager.getConnection() with properties to replace the below 4: -Djavax.net.ssl.keyStore=path_to_keystore_file -Djavax.net.ssl.keyStorePassword=* -Djavax.net.ssl.trustStore=path_to_truststore_file -Djavax.net.ssl.trustStorePassword=* futhermore, adding a property - useSSL and - requireSSL would also help. plus the socketFactory-Class I asked for before (COM-2747) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (DBCP-217) Closing of underlaying connection instead of the PoolGuardConnectionWrapper
[ https://issues.apache.org/jira/browse/DBCP-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom resolved DBCP-217. - Resolution: Fixed Fixed as part of DBCP-11. Closing of underlaying connection instead of the PoolGuardConnectionWrapper --- Key: DBCP-217 URL: https://issues.apache.org/jira/browse/DBCP-217 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.2 Reporter: Sebastian Mancke Fix For: 1.3 Attachments: connectionCloseFix.patch Is state: If I obtain the Connection of a Statement (stmt.getConnection()), created with dbcp, the returned Object is the underlaying pooled connection. Closing this connection multiple times may close the connection of another process. It should be: The Wrapper over the connection PoolGuardConnectionWrapper should be returned instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (DBCP-150) [dbcp] BasicDataSource : setter for connectionProperties
[ https://issues.apache.org/jira/browse/DBCP-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom resolved DBCP-150. - Resolution: Fixed Sendingsrc/java/org/apache/commons/dbcp/BasicDataSource.java Sendingsrc/test/org/apache/commons/dbcp/TestBasicDataSource.java Transmitting file data .. Committed revision 558845. [dbcp] BasicDataSource : setter for connectionProperties Key: DBCP-150 URL: https://issues.apache.org/jira/browse/DBCP-150 Project: Commons Dbcp Issue Type: Improvement Affects Versions: 1.2 Environment: Operating System: All Platform: All Reporter: Maarten Bosteels Assignee: Dain Sundstrom Priority: Minor Fix For: 1.3 Attachments: DBCP-150.patch Adding a javabean-style setter for connectionProperties would certainly ease the configuration of a BasicDataSource within a Dependency Injection framework (eg Spring). see: http://article.gmane.org/gmane.comp.java.springframework.user/6501/ Thanks, Maarten -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (DBCP-225) getConnection / borrowObject fails with NullPointerException
[ https://issues.apache.org/jira/browse/DBCP-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom resolved DBCP-225. - Resolution: Fixed Sendingsrc/java/org/apache/commons/dbcp/PoolableConnectionFactory.java Sending src/java/org/apache/commons/dbcp/datasources/CPDSConnectionFactory.java Sending src/java/org/apache/commons/dbcp/datasources/KeyedCPDSConnectionFactory.java Transmitting file data ... Committed revision 558846. getConnection / borrowObject fails with NullPointerException Key: DBCP-225 URL: https://issues.apache.org/jira/browse/DBCP-225 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.1, 1.2.2 Environment: Solaris 10, Oracle 10g RAC Reporter: Alexei Samonov Assignee: Dain Sundstrom Fix For: 1.3 Attachments: DBCP-225.patch We use dbcp PoolingDataSource in Solaris/Oracle 10g RAC environment and our getConnection calls fail sporadically with the following stack trace (1.2.1) Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool exhausted at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:103) at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540) ... more Caused by: java.util.NoSuchElementException: Could not create a validated object, cause: null at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:806) at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95) ... 24 more This is definitely not a pool exhausted situation, it is just being reported as pool exhausted. Since NoSuchElementException that you use does not allow cause, only Exception message (null) is being printed. With some debugging I was able to recover the root exception: java.lang.NullPointerException at org.apache.commons.dbcp.DelegatingConnection.setAutoCommit(DelegatingConnection.java:268) at org.apache.commons.dbcp.PoolableConnectionFactory.activateObject(PoolableConnectionFactory.java:368) at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:786) at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95) at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540) ... Looks like it is trying to borrow/validate DelegatingConnection which delegate is null. Hoping to resolve the issue we upgraded to 1.2.2 but it did not help. Here is is an exception stack trace from 1.2.2: org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool error Could not create a validated object, cause: null at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:104) at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:880) ... more Caused by: java.util.NoSuchElementException: Could not create a validated object, cause: null at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:871) at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:96) ... 28 more We use the following dbcp properties: autoCommit=false readOnly=false maxActive=200 maxIdle=20 minIdle=10 minEvictableIdleIime=30 maxWait=200 accessToUnderlyingConnectionAllowed=true validationQuery=SELECT 1 FROM DUAL ConnectionCachingEnabled=true FastConnectionFailoverEnabled=true I could not find the existing reported dbcp/object pool bug but I see similar reports on the web, for example http://forum.java.sun.com/thread.jspa?threadID=713200messageID=4124915 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (DBCP-234) Only set *configured* default values for Connection
Only set *configured* default values for Connection --- Key: DBCP-234 URL: https://issues.apache.org/jira/browse/DBCP-234 Project: Commons Dbcp Issue Type: Improvement Reporter: Dain Sundstrom Fix For: 1.3 All default values for connections (auto-commit, read-only, transaction isolation, etc) should be non-primitive types, so it can be determined if they were configured by the user. Only default values configured by the user should be set on connections. This will help to avoid problems where drivers don't support the invocation of methods like setReadOnly and lets driver default values pass through to the user. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (DBCP-207) DBCP 1.2.1 incompatible with Informix (driver doesn't support setReadOnly(...))
[ https://issues.apache.org/jira/browse/DBCP-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom resolved DBCP-207. - Resolution: Fixed Committed a fix for this specific problem, and created a JIRA for converting all default values to non-primitive types. This way only configured default values will be set. Sending src/java/org/apache/commons/dbcp/datasources/PerUserPoolDataSource.java Sending src/java/org/apache/commons/dbcp/datasources/SharedPoolDataSource.java Transmitting file data .. Committed revision 558850. DBCP 1.2.1 incompatible with Informix (driver doesn't support setReadOnly(...)) --- Key: DBCP-207 URL: https://issues.apache.org/jira/browse/DBCP-207 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.1 Environment: using the pooling driver component with an informix driver Reporter: Kimberly Baer Assignee: Dain Sundstrom Fix For: 1.3 Attachments: DBCP-207.patch I recieved an error using commons-dbcp-1.2.1.jar and ifxjdbc.jar for my informix driver: org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool exhausted at org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:183) at java.sql.DriverManager.getConnection(DriverManager.java:539) at java.sql.DriverManager.getConnection(DriverManager.java:211) at ConnectionPoolingTest.main(ConnectionPoolingTest.java:105) Caused by: java.util.NoSuchElementException: Could not create a validated object, cause: Read only mode not supported at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:806) at org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:175) I will look into the comment provided by Dirk in bug ID DBCP-127 (version 1.1), but it appears this bug still has an impact in the 1.2.1 version. If anyone has any other suggestions, they would be greatly appreciated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (DBCP-221) How to close the connection pool without shutting down the JVM while there are connections being used?
[ https://issues.apache.org/jira/browse/DBCP-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom resolved DBCP-221. - Resolution: Fixed Assignee: Dain Sundstrom BasicDataSource.close() now permanently marks the data source as closed. No new connections can be obtained from a closed data source. At close all idle connections are destroyed and the method returns. As existing active connections are closed, they are destroyed. How to close the connection pool without shutting down the JVM while there are connections being used? -- Key: DBCP-221 URL: https://issues.apache.org/jira/browse/DBCP-221 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.2 Reporter: Bill Liu Assignee: Dain Sundstrom Fix For: 1.3 Suppose there are several connections being used now by different servlets. calling the basicDataSource,close() does not have any impact on the connection pool. I expect that after these servlet return the connections the pool should be shut down immediately. I also expect that any more requests to borrow connections from the pool should not be fulfilled. However, my experiment does not seem to support my expectations. Calling basicDataSource.close() seems to be ignored while there are connections being used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (DBCP-235) accessToUnderlyingConnectionAllowed flag in ManagedConnection breaks equals, hashCode and toString
accessToUnderlyingConnectionAllowed flag in ManagedConnection breaks equals, hashCode and toString --- Key: DBCP-235 URL: https://issues.apache.org/jira/browse/DBCP-235 Project: Commons Dbcp Issue Type: Bug Reporter: Dain Sundstrom Fix For: 1.3 The accessToUnderlyingConnectionAllowed property ManageConnection disables the getInnerMostDelegate method used by DelegatingConnection equals, hashCode, and toString. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DBCP-152) [DBCP] add a socketFactory attribute to BasicDataSource (to allow SSL thread-safe)
[ https://issues.apache.org/jira/browse/DBCP-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514273 ] Dain Sundstrom commented on DBCP-152: - Ralf, Security is a very important issue for me, so I'm not saying that I don't want to support security features or that I don't want anyone to implement security fixes. You are requesting that we add a socketFactory factory property to DBCP, which is about 7 lines of code. The problem is once we add this property, we have no standard way to pass this information to the JDBC driver. One option, as you have suggested, is to add the socketFactory property to the properties object passed to driver.connect(url, properties). If that is your ultimate goal, we already have a mechanism in DBCP to pass properties to the connection factory addConnectionProperty(name, value). Additionally, since there is no standard for this property, it is likely that any vendor that supported the property chose a different name (e.g., socketFactoryName, sockteFactoryClass, etc.). There are other databases that pass this type of connection security information via the JDBC connect URL, which makes since since the security properties apply to all connections and not just a single connection. Unfortunately, there is no standard way to encode properties into a JDBC connect URL. Fortunately, we have a standard set the connect URL setUrl(url). To reiterate, security is very important to me, and if there were a standard way to support this type of configuration, I would submit a patch. In this specific case, I think there is any way to support your request without it being vendor specific, and I do not want to see DBCP expanded with vendor specific extensions. I suggest that you make a request for enhancement with the JDBC expert group (http://jcp.org/en/jsr/detail?id=221), and if they approve security enhancements, we will support them. [DBCP] add a socketFactory attribute to BasicDataSource (to allow SSL thread-safe) Key: DBCP-152 URL: https://issues.apache.org/jira/browse/DBCP-152 Project: Commons Dbcp Issue Type: Improvement Affects Versions: 1.2 Environment: Operating System: All Platform: Other Reporter: Ralf Hauser Priority: Minor Fix For: 1.3 An app that accesses 2 datasources at two different places with different security policies via SSL (different set of permitted ciphers) currently is out of luck (http://lists.mysql.com/java/8689). The basic datasource should be enhanced with String socketFactory = ; and the corresponding getter and setter method, etc. org.apache.commons.dbcp.DriverConnectionFactory.createConnection() could then hand-over this full className via its Properties argument to enable different SSL policies per datasource (so, since the application programmer doesn't have the thread under her control, I guess it should rather be called dataSource-safe). The jdbc driver implementation can then use this to take the appropriate socket factory when creating a connection. See also http://lists.mysql.com/java/8695 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-44) [dbcp] Evictor thread in GenericObjectPool has potential for deadlock
[ https://issues.apache.org/jira/browse/DBCP-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom updated DBCP-44: --- Attachment: DBCP-44.patch This is an architectural problem in commons-pool. GenericObjectPool.borrowObject() is synchronized so when it needs to make a new object, that method is called within a synchronized block. Here are the stack traces of the deal lock in our case: [EMAIL PROTECTED], priority=5, in group 'main', status: 'MONITOR' blocks [EMAIL PROTECTED] waiting for [EMAIL PROTECTED] borrowObject():781, GenericObjectPool.java connect():176, PoolingDriver.java getConnection():525, DriverManager.java getConnection():140, DriverManager.java main():107, Deadlock.java [EMAIL PROTECTED] daemon, priority=5, in group 'main', status: 'MONITOR' blocks [EMAIL PROTECTED] waiting for [EMAIL PROTECTED] getConnection():138, DriverManager.java createConnection():68, DriverManagerConnectionFactory.java makeObject():329, PoolableConnectionFactory.java addObject():1059, GenericObjectPool.java ensureMinIdle():1040, GenericObjectPool.java access$100():128, GenericObjectPool.java run():1117, GenericObjectPool.java mainLoop():512, Timer.java run():462, Timer.java This is a classic two lock dead lock. The main thread acquires the locks on DriveManager then GenericObjectPool, and at the same time the timer thread attempts to acquire them in the opposite order GenericObjectPool and then DriveManger. There are really only two ways to fix this 1) guarantee locks are always acquired in the same order or 2) eliminate one of the locks. The first one is not really possible as both objects are generally publicly accessible, and the second fix will require a complex change to the GenericObjectPool code. Attached is a patch that adds the Deadlock class, which has a main method that causes the dead lock.The patch also fixes the synchronization in PoolableConnectionFactory. I also added property to TesterDriver to cause the thread to sleep in getConnection so the dead lock can be reproduced. I'm going to attempt to write a new pool using the Java5 concurrent code which doesn't call makeObject inside of a synchronized block. [dbcp] Evictor thread in GenericObjectPool has potential for deadlock - Key: DBCP-44 URL: https://issues.apache.org/jira/browse/DBCP-44 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.1 Environment: Operating System: All Platform: All Reporter: Eric Layton Fix For: 1.3 Attachments: DBCP-44.patch, deadlock.txt, deadlock_post_patch.txt, testConcurrency.java The GenericObjectPool Evictor thread can potentially cause a deadlock between its connection factory and java.sql.DriverManager. The deadlock occurs when the Evictor thread is trying to make enough connections to bring the pool's idle connections up to what's specified in minIdle, at the same time a connection is being requested through DriverManager.getConnection(). See the attached stack trace dump: Found one Java-level deadlock: = Thread-0: waiting to lock monitor 0x0809a994 (object 0x698c2b48, a java.lang.Class), which is held by main main: waiting to lock monitor 0x0809aad4 (object 0x65df7030, a org.apache.commons.dbcp.PoolableConnectionFactory), which is held by Thread-0 Java stack information for the threads listed above: === Thread-0: at java.sql.DriverManager.getConnection(DriverManager.java:158) - waiting to lock 0x698c2b48 (a java.lang.Class) at org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:48) at org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290) - locked 0x65df7030 (a org.apache.commons.dbcp.PoolableConnectionFactory) at org.apache.commons.pool.impl.GenericObjectPool.addObject(GenericObjectPool.java:996) at org.apache.commons.pool.impl.GenericObjectPool.ensureMinIdle(GenericObjectPool.java:978) at org.apache.commons.pool.impl.GenericObjectPool.access$000(GenericObjectPool.java:124) at org.apache.commons.pool.impl.GenericObjectPool$Evictor.run(GenericObjectPool.java:1090) at java.lang.Thread.run(Thread.java:595) main: at org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290) - waiting to lock 0x65df7030 (a org.apache.commons.dbcp.PoolableConnectionFactory) at
[jira] Commented: (DBCP-44) [dbcp] Evictor thread in GenericObjectPool has potential for deadlock
[
https://issues.apache.org/jira/browse/DBCP-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514362
]
Dain Sundstrom commented on DBCP-44:
This will take experimentation, but off the top of my head, I'd do somthing
like this:
while(true) {
synchronized(idleCollection) {
if (!idleCollection.isEmpty()) {
return idleCollection.removeFirst();
}
}
Future future = this.allocationFutureAtomic.get();
if (allocationFuture == null) {
future = new AllocationFuture();
if (this.allocationFutureAtomic.weakCompareAndSet(null, future)) {
future.get();
}
}
}
The AllocationFuture would create new connection(s), add them to the idle pool,
and then clear the future atomic. Of course this can be done with primitives,
but it is more painful to code. It would be cleaner to use an executor to
process the future, so it can potentially be done on another thread which isn't
holding locks, and if the makeObject() hangs you, don't have to interrupt an
application thread. All of this becomes more difficult when you try to
implement a keyed pool due to double book keeping of a global count and per key
count.
Anyway, I'll experiment with some implementations and if I come up with
anything good, I'll post it.
[dbcp] Evictor thread in GenericObjectPool has potential for deadlock
-
Key: DBCP-44
URL: https://issues.apache.org/jira/browse/DBCP-44
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.2.1
Environment: Operating System: All
Platform: All
Reporter: Eric Layton
Fix For: 1.3
Attachments: DBCP-44.patch, deadlock.txt, deadlock_post_patch.txt,
testConcurrency.java
The GenericObjectPool Evictor thread can potentially cause a deadlock between
its connection factory and java.sql.DriverManager. The deadlock occurs when
the
Evictor thread is trying to make enough connections to bring the pool's idle
connections up to what's specified in minIdle, at the same time a connection
is
being requested through DriverManager.getConnection(). See the attached stack
trace dump:
Found one Java-level deadlock:
=
Thread-0:
waiting to lock monitor 0x0809a994 (object 0x698c2b48, a java.lang.Class),
which is held by main
main:
waiting to lock monitor 0x0809aad4 (object 0x65df7030, a
org.apache.commons.dbcp.PoolableConnectionFactory),
which is held by Thread-0
Java stack information for the threads listed above:
===
Thread-0:
at java.sql.DriverManager.getConnection(DriverManager.java:158)
- waiting to lock 0x698c2b48 (a java.lang.Class)
at
org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:48)
at
org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
- locked 0x65df7030 (a
org.apache.commons.dbcp.PoolableConnectionFactory)
at
org.apache.commons.pool.impl.GenericObjectPool.addObject(GenericObjectPool.java:996)
at
org.apache.commons.pool.impl.GenericObjectPool.ensureMinIdle(GenericObjectPool.java:978)
at
org.apache.commons.pool.impl.GenericObjectPool.access$000(GenericObjectPool.java:124)
at
org.apache.commons.pool.impl.GenericObjectPool$Evictor.run(GenericObjectPool.java:1090)
at java.lang.Thread.run(Thread.java:595)
main:
at
org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
- waiting to lock 0x65df7030 (a
org.apache.commons.dbcp.PoolableConnectionFactory)
at
org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:771)
at
org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:175)
at java.sql.DriverManager.getConnection(DriverManager.java:525)
- locked 0x698c2b48 (a java.lang.Class)
at java.sql.DriverManager.getConnection(DriverManager.java:193)
- locked 0x698c2b48 (a java.lang.Class)
at Deadlock.main(Deadlock.java:83)
Found 1 deadlock.
The deadlock occurs when GenericObjectPool.addObject() calls synchronized
method
PoolableConnectionFactory.makeObject(), meanwhile static synchronized
DriverManager.getConnection() is called. makeObject() waits for the lock on
DriverManager to be released, whereas DriverManager waits for the lock on the
PoolableConnectionFactory instance to be released.
The Java program below, based on ManualPoolingDriverExample.java provided with
DBCP, duplicates the deadlock for me within several seconds of being run:
import java.sql.*;
import org.apache.commons.pool.*;
import org.apache.commons.pool.impl.*;
import
[jira] Commented: (DBCP-44) [dbcp] Evictor thread in GenericObjectPool has potential for deadlock
[
https://issues.apache.org/jira/browse/DBCP-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514364
]
Dain Sundstrom commented on DBCP-44:
BTW it isn't the evictor thread that is problematic per say (it could have
other issues :)). It is the fact that when generic object pool calls
makeObject it is holding a lock on the whole pool. This type of lock holding
open out call is bound to cause dead locks. The example in this issue is a
dead lock between a thread using a DBCP pool to get a connection and a thread
that goes directly to the DriveManager for a connection.
[dbcp] Evictor thread in GenericObjectPool has potential for deadlock
-
Key: DBCP-44
URL: https://issues.apache.org/jira/browse/DBCP-44
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.2.1
Environment: Operating System: All
Platform: All
Reporter: Eric Layton
Fix For: 1.3
Attachments: DBCP-44.patch, deadlock.txt, deadlock_post_patch.txt,
testConcurrency.java
The GenericObjectPool Evictor thread can potentially cause a deadlock between
its connection factory and java.sql.DriverManager. The deadlock occurs when
the
Evictor thread is trying to make enough connections to bring the pool's idle
connections up to what's specified in minIdle, at the same time a connection
is
being requested through DriverManager.getConnection(). See the attached stack
trace dump:
Found one Java-level deadlock:
=
Thread-0:
waiting to lock monitor 0x0809a994 (object 0x698c2b48, a java.lang.Class),
which is held by main
main:
waiting to lock monitor 0x0809aad4 (object 0x65df7030, a
org.apache.commons.dbcp.PoolableConnectionFactory),
which is held by Thread-0
Java stack information for the threads listed above:
===
Thread-0:
at java.sql.DriverManager.getConnection(DriverManager.java:158)
- waiting to lock 0x698c2b48 (a java.lang.Class)
at
org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:48)
at
org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
- locked 0x65df7030 (a
org.apache.commons.dbcp.PoolableConnectionFactory)
at
org.apache.commons.pool.impl.GenericObjectPool.addObject(GenericObjectPool.java:996)
at
org.apache.commons.pool.impl.GenericObjectPool.ensureMinIdle(GenericObjectPool.java:978)
at
org.apache.commons.pool.impl.GenericObjectPool.access$000(GenericObjectPool.java:124)
at
org.apache.commons.pool.impl.GenericObjectPool$Evictor.run(GenericObjectPool.java:1090)
at java.lang.Thread.run(Thread.java:595)
main:
at
org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
- waiting to lock 0x65df7030 (a
org.apache.commons.dbcp.PoolableConnectionFactory)
at
org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:771)
at
org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:175)
at java.sql.DriverManager.getConnection(DriverManager.java:525)
- locked 0x698c2b48 (a java.lang.Class)
at java.sql.DriverManager.getConnection(DriverManager.java:193)
- locked 0x698c2b48 (a java.lang.Class)
at Deadlock.main(Deadlock.java:83)
Found 1 deadlock.
The deadlock occurs when GenericObjectPool.addObject() calls synchronized
method
PoolableConnectionFactory.makeObject(), meanwhile static synchronized
DriverManager.getConnection() is called. makeObject() waits for the lock on
DriverManager to be released, whereas DriverManager waits for the lock on the
PoolableConnectionFactory instance to be released.
The Java program below, based on ManualPoolingDriverExample.java provided with
DBCP, duplicates the deadlock for me within several seconds of being run:
import java.sql.*;
import org.apache.commons.pool.*;
import org.apache.commons.pool.impl.*;
import org.apache.commons.dbcp.*;
/**
* Duplicate DBCP pool deadlocking.
*
* Compile with:
* /usr/java/jdk1.5.0/bin/javac
* -classpath
commons-collections.jar:commons-dbcp-1.2.1.jar:commons-pool-1.2.jar
* Deadlock.java
*
* Run with:
* /usr/java/jdk1.5.0/bin/java
* -classpath
commons-collections.jar:commons-dbcp-1.2.1.jar:commons-pool-1.2.jar:ojdbc14.jar:xerces.jar:.
* Deadlock
*
* Locks still occur when compiled and run with J2SDK 1.4.1_03.
*/
public class Deadlock {
private static final int ACTIVE = 10;
private static void init() {
System.out.println(Loading drivers);
try {
[jira] Commented: (DBCP-44) [dbcp] Evictor thread in GenericObjectPool has potential for deadlock
[
https://issues.apache.org/jira/browse/DBCP-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514366
]
Dain Sundstrom commented on DBCP-44:
Ok one more comment before I get lunch My sample code above is bad. It is
a hard loop (duh). Instead of hard looping, the second check on the
idleCollection could wait for a item to become available (easy with a
concurrent queue). Which leave the possibility that someone sneaks in and
steals the new connection we were waiting for :( As, I said it will take some
experimentation to get this right, but that is the fun part.
[dbcp] Evictor thread in GenericObjectPool has potential for deadlock
-
Key: DBCP-44
URL: https://issues.apache.org/jira/browse/DBCP-44
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.2.1
Environment: Operating System: All
Platform: All
Reporter: Eric Layton
Fix For: 1.3
Attachments: DBCP-44.patch, deadlock.txt, deadlock_post_patch.txt,
testConcurrency.java
The GenericObjectPool Evictor thread can potentially cause a deadlock between
its connection factory and java.sql.DriverManager. The deadlock occurs when
the
Evictor thread is trying to make enough connections to bring the pool's idle
connections up to what's specified in minIdle, at the same time a connection
is
being requested through DriverManager.getConnection(). See the attached stack
trace dump:
Found one Java-level deadlock:
=
Thread-0:
waiting to lock monitor 0x0809a994 (object 0x698c2b48, a java.lang.Class),
which is held by main
main:
waiting to lock monitor 0x0809aad4 (object 0x65df7030, a
org.apache.commons.dbcp.PoolableConnectionFactory),
which is held by Thread-0
Java stack information for the threads listed above:
===
Thread-0:
at java.sql.DriverManager.getConnection(DriverManager.java:158)
- waiting to lock 0x698c2b48 (a java.lang.Class)
at
org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:48)
at
org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
- locked 0x65df7030 (a
org.apache.commons.dbcp.PoolableConnectionFactory)
at
org.apache.commons.pool.impl.GenericObjectPool.addObject(GenericObjectPool.java:996)
at
org.apache.commons.pool.impl.GenericObjectPool.ensureMinIdle(GenericObjectPool.java:978)
at
org.apache.commons.pool.impl.GenericObjectPool.access$000(GenericObjectPool.java:124)
at
org.apache.commons.pool.impl.GenericObjectPool$Evictor.run(GenericObjectPool.java:1090)
at java.lang.Thread.run(Thread.java:595)
main:
at
org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
- waiting to lock 0x65df7030 (a
org.apache.commons.dbcp.PoolableConnectionFactory)
at
org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:771)
at
org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:175)
at java.sql.DriverManager.getConnection(DriverManager.java:525)
- locked 0x698c2b48 (a java.lang.Class)
at java.sql.DriverManager.getConnection(DriverManager.java:193)
- locked 0x698c2b48 (a java.lang.Class)
at Deadlock.main(Deadlock.java:83)
Found 1 deadlock.
The deadlock occurs when GenericObjectPool.addObject() calls synchronized
method
PoolableConnectionFactory.makeObject(), meanwhile static synchronized
DriverManager.getConnection() is called. makeObject() waits for the lock on
DriverManager to be released, whereas DriverManager waits for the lock on the
PoolableConnectionFactory instance to be released.
The Java program below, based on ManualPoolingDriverExample.java provided with
DBCP, duplicates the deadlock for me within several seconds of being run:
import java.sql.*;
import org.apache.commons.pool.*;
import org.apache.commons.pool.impl.*;
import org.apache.commons.dbcp.*;
/**
* Duplicate DBCP pool deadlocking.
*
* Compile with:
* /usr/java/jdk1.5.0/bin/javac
* -classpath
commons-collections.jar:commons-dbcp-1.2.1.jar:commons-pool-1.2.jar
* Deadlock.java
*
* Run with:
* /usr/java/jdk1.5.0/bin/java
* -classpath
commons-collections.jar:commons-dbcp-1.2.1.jar:commons-pool-1.2.jar:ojdbc14.jar:xerces.jar:.
* Deadlock
*
* Locks still occur when compiled and run with J2SDK 1.4.1_03.
*/
public class Deadlock {
private static final int ACTIVE = 10;
private static void init() {
System.out.println(Loading drivers);
try {
[jira] Commented: (DBCP-209) Is DataSource.getConnection(user, pass) working the way it is suppose to?
[ https://issues.apache.org/jira/browse/DBCP-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514033 ] Dain Sundstrom commented on DBCP-209: - I believe that Michael should be using either the SharedPoolDataSource or the PerUserPoolDataSource which support the getConnection(user, pass) method. This pool keeps track of connection credentials, so when a connection is created, it can locate a connection authorized for the specified user. I think this issue should be closed as invalid. Is DataSource.getConnection(user, pass) working the way it is suppose to? - Key: DBCP-209 URL: https://issues.apache.org/jira/browse/DBCP-209 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.1 Reporter: Michael Remijan Fix For: 1.3 In Tomcat's server.xml, I create a DataSource resource using the FACTORY org.apache.commons.dbcp.BasicDataSourceFactory and I also provide a URL and a DRIVERCLASSNAME. However I do not provide USERNAME or PASSWORD because I want to use DataSource.getConnection(user, pass) in my application. When I call DataSource.getConnection(user, pass) I get the following exception, java.sql.SQLException: invalid arguments in call, which was unexpected. I dug into the source code for BasicDataSource and I found what I think is the source of the problem. First, the method getConnection(user, pass) call the createDataSource() method. The createDataSource() method creates a Properties object and tries to put the username and password into the properties object. However, because the server.xml file does contain a username or password, this Properties object (named connectionProperties in the code) is empty. The createDataSource() the proceeds to call the validateConnectionFactory() method. This method then tries to get a Connection object!! This attempt fails because the Properties object has no username or password in it hence the Oracle driver complains about being passed invalid arguments. My question is why is the code working this way? Why does the createDataSource() and validateConnectionFactory() methods assume the username and password have been set in server.xml and then attempt to try to return a Connection object with the username and password passed to the getConnection(user, pass) method? It would seem to me the createDataSource() and validateConnectionFactory() methods should be aware of the username and password passed to the getConnection(user, pass) if this method is used. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DBCP-53) [dbcp] commons dbcp does not supports Firebird DB.
[
https://issues.apache.org/jira/browse/DBCP-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514039
]
Dain Sundstrom commented on DBCP-53:
I don't think this is a DBCP issue. My guess is your torque configuration is
wrong, but I'm not torque expert. The
org.apache.commons.dbcp.cpdsadapter.DriverAdapterCPDS class has the following
method:
public void setDriver(String v) throws ClassNotFoundException {
assertInitializationAllowed();
this.driver = v;
// make sure driver is registered
Class.forName(v);
}
Which can fail for two reasons. First, if any connections have already been
allocated from the data source, the assertInitializationAllowed method will
throw and IllegalStateException because the data source is already actively
creating connections for a data base. The second place this method can fail is
the call to Class.forName. In either case, I don't think it is a DBCP issue.
I think we should close this as invalid, and if Torque team find a bug in DBCP,
they can open a new issue.
[dbcp] commons dbcp does not supports Firebird DB.
--
Key: DBCP-53
URL: https://issues.apache.org/jira/browse/DBCP-53
Project: Commons Dbcp
Issue Type: Bug
Environment: Operating System: Windows XP
Platform: PC
Reporter: DMoL
Fix For: 1.3
I'm trying to use Torque-3.2 with open-source Firebird DBMS, but simple
example
not works. Here is the log output:
15.03.2006 21:47:38 org.apache.torque.dsfactory.AbstractDataSourceFactory
setProperty
SEVERE: Property: driver value: org.firebirdsql.jdbc.FBDriver is not supported
by DataSource: org.apache.commons.dbcp.cpdsadapter.DriverAdapterCPDS
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DBCP-97) setAutoCommit(true) when returning connection to the pool
[
https://issues.apache.org/jira/browse/DBCP-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514044
]
Dain Sundstrom commented on DBCP-97:
Yes, this is correct. When auto commit is off, you have an open transaction
with the database, so leaving auto commit off while a connection is idle in the
pool is a bad idea.
One note. The current passivate code has the following block:
conn.clearWarnings();
if(!conn.getAutoCommit()) {
conn.setAutoCommit(true);
}
Do we want the clearWarnings() after the potential autocommit change?
setAutoCommit(true) when returning connection to the pool
-
Key: DBCP-97
URL: https://issues.apache.org/jira/browse/DBCP-97
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: Nightly Builds
Environment: Operating System: All
Platform: All
Reporter: Dirk Verbeeck
Fix For: 1.3
From the Struts user list: [OT] RE: Stackoverflow after DB inactivity
(MySQL reconnect problem)
http://www.mail-archive.com/[EMAIL PROTECTED]/msg70196.html
Giving a hint to the database driver that you don't need long running
transactions makes sense.
setAutoCommit(true) should be added to
PoolableConnectionFactory.passivateObject
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DBCP-155) [dbcp] allow to set = 6 parameters to do non-global SSL
[ https://issues.apache.org/jira/browse/DBCP-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514053 ] Dain Sundstrom commented on DBCP-155: - DBCP has support for JDBC connection properties. The JSSE properties you list above are not JDBC properties, and must be set as Java system properties. Unfortunately, that is how the JSSE specification works. Any changes to JSSE are beyond the scope of DBCP. I suggest we close this as won't fix. [dbcp] allow to set = 6 parameters to do non-global SSL Key: DBCP-155 URL: https://issues.apache.org/jira/browse/DBCP-155 Project: Commons Dbcp Issue Type: Improvement Environment: Operating System: All Platform: Other Reporter: Ralf Hauser Priority: Minor Fix For: 1.3 to work with http://dev.mysql.com/doc/refman/5.1/en/cj-using-ssl.html, it should be possible to call DriverManager.getConnection() with properties to replace the below 4: -Djavax.net.ssl.keyStore=path_to_keystore_file -Djavax.net.ssl.keyStorePassword=* -Djavax.net.ssl.trustStore=path_to_truststore_file -Djavax.net.ssl.trustStorePassword=* futhermore, adding a property - useSSL and - requireSSL would also help. plus the socketFactory-Class I asked for before (COM-2747) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DBCP-152) [DBCP] add a socketFactory attribute to BasicDataSource (to allow SSL thread-safe)
[ https://issues.apache.org/jira/browse/DBCP-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514054 ] Dain Sundstrom commented on DBCP-152: - DBCP supports JDBC standard properties, so if mysql ssl can be configured via JDBC properties, this already works. Unfortunately, it appears mysql ssl can not be configured this way, and this is effectively request for mysql specific features which are beyond the scope of DBCP. I suggest we close this as won't fix. [DBCP] add a socketFactory attribute to BasicDataSource (to allow SSL thread-safe) Key: DBCP-152 URL: https://issues.apache.org/jira/browse/DBCP-152 Project: Commons Dbcp Issue Type: Improvement Affects Versions: 1.2 Environment: Operating System: All Platform: Other Reporter: Ralf Hauser Priority: Minor Fix For: 1.3 An app that accesses 2 datasources at two different places with different security policies via SSL (different set of permitted ciphers) currently is out of luck (http://lists.mysql.com/java/8689). The basic datasource should be enhanced with String socketFactory = ; and the corresponding getter and setter method, etc. org.apache.commons.dbcp.DriverConnectionFactory.createConnection() could then hand-over this full className via its Properties argument to enable different SSL policies per datasource (so, since the application programmer doesn't have the thread under her control, I guess it should rather be called dataSource-safe). The jdbc driver implementation can then use this to take the appropriate socket factory when creating a connection. See also http://lists.mysql.com/java/8695 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-110) [dbcp] DBCP removeAbandoned not working
[ https://issues.apache.org/jira/browse/DBCP-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom updated DBCP-110: Summary: [dbcp] DBCP removeAbandoned not working (was: [dbcp] Problem reported at forum.java.sun.com) [dbcp] DBCP removeAbandoned not working --- Key: DBCP-110 URL: https://issues.apache.org/jira/browse/DBCP-110 Project: Commons Dbcp Issue Type: Bug Environment: Operating System: other Platform: Other Reporter: David Smiley Priority: Minor Fix For: 1.3 Read the details at the URL. It includes a fix, I think. http://forum.java.sun.com/thread.jspa?threadID=658047tstart=0 I think I've run across this bug too, a couple days ago. I'm not sure if it exactly the same issue but I got the same underlying exception: java.util.NoSuchElementException: Timeout waiting for idle object I'm using Atlantassian Confluence which is using DBCP. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-207) DBCP 1.2.1 incompatible with Informix (driver doesn't support setReadOnly(...))
[ https://issues.apache.org/jira/browse/DBCP-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom updated DBCP-207: Attachment: DBCP-207.patch Already fixed for PoolingDataSource, but PerUserDataSource and SharedPoolDataSource still always set this value. These data sources use a primitives for the read only, transaction isolation and auto commit default values so there is not way to see if the value was not set. This patch checks if the read-only and auto-commit values are already set before changing them which should setReadOnly from being called. DBCP 1.2.1 incompatible with Informix (driver doesn't support setReadOnly(...)) --- Key: DBCP-207 URL: https://issues.apache.org/jira/browse/DBCP-207 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.1 Environment: using the pooling driver component with an informix driver Reporter: Kimberly Baer Fix For: 1.3 Attachments: DBCP-207.patch I recieved an error using commons-dbcp-1.2.1.jar and ifxjdbc.jar for my informix driver: org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool exhausted at org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:183) at java.sql.DriverManager.getConnection(DriverManager.java:539) at java.sql.DriverManager.getConnection(DriverManager.java:211) at ConnectionPoolingTest.main(ConnectionPoolingTest.java:105) Caused by: java.util.NoSuchElementException: Could not create a validated object, cause: Read only mode not supported at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:806) at org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:175) I will look into the comment provided by Dirk in bug ID DBCP-127 (version 1.1), but it appears this bug still has an impact in the 1.2.1 version. If anyone has any other suggestions, they would be greatly appreciated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-150) [dbcp] BasicDataSource : setter for connectionProperties
[ https://issues.apache.org/jira/browse/DBCP-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom updated DBCP-150: Attachment: DBCP-150.patch Implementation, java doc and test case [dbcp] BasicDataSource : setter for connectionProperties Key: DBCP-150 URL: https://issues.apache.org/jira/browse/DBCP-150 Project: Commons Dbcp Issue Type: Improvement Affects Versions: 1.2 Environment: Operating System: All Platform: All Reporter: Maarten Bosteels Priority: Minor Fix For: 1.3 Attachments: DBCP-150.patch Adding a javabean-style setter for connectionProperties would certainly ease the configuration of a BasicDataSource within a Dependency Injection framework (eg Spring). see: http://article.gmane.org/gmane.comp.java.springframework.user/6501/ Thanks, Maarten -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-225) getConnection / borrowObject fails with NullPointerException
[ https://issues.apache.org/jira/browse/DBCP-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom updated DBCP-225: Attachment: DBCP-225.patch This patch checks for null returned from connection factory and throws an IllegalStateException. We may want to go with a SQLException instead. I don't think this will fix Alexei's problem, but at least will cause a fast failure instead of getting a strange hollow connection. Alternatively, if we just need to ask Oracle again for a connection, we could put a retry loop in the connection factory. getConnection / borrowObject fails with NullPointerException Key: DBCP-225 URL: https://issues.apache.org/jira/browse/DBCP-225 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.1, 1.2.2 Environment: Solaris 10, Oracle 10g RAC Reporter: Alexei Samonov Fix For: 1.3 Attachments: DBCP-225.patch We use dbcp PoolingDataSource in Solaris/Oracle 10g RAC environment and our getConnection calls fail sporadically with the following stack trace (1.2.1) Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool exhausted at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:103) at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540) ... more Caused by: java.util.NoSuchElementException: Could not create a validated object, cause: null at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:806) at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95) ... 24 more This is definitely not a pool exhausted situation, it is just being reported as pool exhausted. Since NoSuchElementException that you use does not allow cause, only Exception message (null) is being printed. With some debugging I was able to recover the root exception: java.lang.NullPointerException at org.apache.commons.dbcp.DelegatingConnection.setAutoCommit(DelegatingConnection.java:268) at org.apache.commons.dbcp.PoolableConnectionFactory.activateObject(PoolableConnectionFactory.java:368) at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:786) at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95) at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540) ... Looks like it is trying to borrow/validate DelegatingConnection which delegate is null. Hoping to resolve the issue we upgraded to 1.2.2 but it did not help. Here is is an exception stack trace from 1.2.2: org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool error Could not create a validated object, cause: null at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:104) at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:880) ... more Caused by: java.util.NoSuchElementException: Could not create a validated object, cause: null at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:871) at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:96) ... 28 more We use the following dbcp properties: autoCommit=false readOnly=false maxActive=200 maxIdle=20 minIdle=10 minEvictableIdleIime=30 maxWait=200 accessToUnderlyingConnectionAllowed=true validationQuery=SELECT 1 FROM DUAL ConnectionCachingEnabled=true FastConnectionFailoverEnabled=true I could not find the existing reported dbcp/object pool bug but I see similar reports on the web, for example http://forum.java.sun.com/thread.jspa?threadID=713200messageID=4124915 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-11) [dbcp] stmt.getConnection() != Connection used to create the statement
[ https://issues.apache.org/jira/browse/DBCP-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom updated DBCP-11: --- Attachment: back-pointers.patch This patch assures that all all returned Statements, PreparedStatements, CallableStatements and ResultSets are wrapped with a delegating object, which already properly handle the back pointers for Connection and Statement. This patch includes an extensive test to assure that the *same* object used to create the statement or result set is returned from either the getConnection() or getStatementMethod(). [dbcp] stmt.getConnection() != Connection used to create the statement -- Key: DBCP-11 URL: https://issues.apache.org/jira/browse/DBCP-11 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2 Environment: Operating System: other Platform: All Reporter: Alexander Rupsch Fix For: 1.3 Attachments: back-pointers.patch Hi, I'm not an expert in implementing connection pools or jdbc itself. But shouldn't the following code work? Connection con = pool.getConnection() PreparedStatement ps = con.prepareStatement() con.equals(ps.getConnection) // returns false! Ok, I don't need it to be equal, but the following also does not work: ps.getConnection().close() con.isClosed() // is false!!! That means, if I have a Statment and want to close its connection, I have to remember the conncetion. Is that the requested behavior? Because of this my pool is running over. The java.sql API says that Statment.getConnection() has to be the connection which created the statement. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (DBCP-233) Allow connection, statement, and result set to be closed multiple times
Allow connection, statement, and result set to be closed multiple times --- Key: DBCP-233 URL: https://issues.apache.org/jira/browse/DBCP-233 Project: Commons Dbcp Issue Type: Improvement Reporter: Dain Sundstrom Fix For: 1.3 Attachments: CloseTwice.patch This patch allows Connection, Statement, PreparedStatement, CallableStatement and ResultSet to be closed multiple times. The first time close is called the resource is closed and any subsequent calls have no effect. This behavior is required as per the JavaDocs for these classes. The patch adds tests for closing all types multiple times and updates any tests that incorrectly assert that a resource can be closed more then once. This patch fixes DBCP-134 and DBCP-3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-233) Allow connection, statement, and result set to be closed multiple times
[ https://issues.apache.org/jira/browse/DBCP-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom updated DBCP-233: Attachment: CloseTwice.patch Allow connection, statement, and result set to be closed multiple times --- Key: DBCP-233 URL: https://issues.apache.org/jira/browse/DBCP-233 Project: Commons Dbcp Issue Type: Improvement Reporter: Dain Sundstrom Fix For: 1.3 Attachments: CloseTwice.patch This patch allows Connection, Statement, PreparedStatement, CallableStatement and ResultSet to be closed multiple times. The first time close is called the resource is closed and any subsequent calls have no effect. This behavior is required as per the JavaDocs for these classes. The patch adds tests for closing all types multiple times and updates any tests that incorrectly assert that a resource can be closed more then once. This patch fixes DBCP-134 and DBCP-3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (DBCP-230) [DBCP] BasicManagedDataSource
[DBCP] BasicManagedDataSource - Key: DBCP-230 URL: https://issues.apache.org/jira/browse/DBCP-230 Project: Commons Dbcp Issue Type: New Feature Reporter: Dain Sundstrom Fix For: 1.3 This patch creates an extension to the BasicDataSource which creates ManagedConnection. This class allows easy usage of the ManagedDataSource from environments that configure via JavaBeans properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-230) [DBCP] BasicManagedDataSource
[ https://issues.apache.org/jira/browse/DBCP-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom updated DBCP-230: Attachment: BasicManagedDataSource.patch [DBCP] BasicManagedDataSource - Key: DBCP-230 URL: https://issues.apache.org/jira/browse/DBCP-230 Project: Commons Dbcp Issue Type: New Feature Reporter: Dain Sundstrom Fix For: 1.3 Attachments: BasicManagedDataSource.patch This patch creates an extension to the BasicDataSource which creates ManagedConnection. This class allows easy usage of the ManagedDataSource from environments that configure via JavaBeans properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-228) [dbcp] Managed Connection support
[ https://issues.apache.org/jira/browse/DBCP-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dain Sundstrom updated DBCP-228: Attachment: ManagedConnection.patch [dbcp] Managed Connection support - Key: DBCP-228 URL: https://issues.apache.org/jira/browse/DBCP-228 Project: Commons Dbcp Issue Type: New Feature Reporter: Dain Sundstrom Attachments: ManagedConnection.patch This patch adds support for pooling of ManagedConnections. A managed connection is responsible for managing a database connection in a transactional environment (typically called Container Managed). A managed connection opperates like any other connection when no gloabal transaction (a.k.a. XA transaction or JTA Transaction) is in progress. When a global transaction is active a single physical connection to the database is used by all ManagedConnections accessed in the scope of the transaction. Connection sharing means that all data access during a transaction has a consistent view of the database. When the global transaction is committed or rolled back the enlisted connections are committed or rolled back. This patch supports full XADataSources and non-XA data sources using local transaction semantics. non-XA data sources commit and rollback as part of the transaction but are not recoverable in the case of an error because they do not implement the two-phase commit protocol. The patch includes test cases and javadoc comments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (DBCP-228) [dbcp] Managed Connection support
[dbcp] Managed Connection support - Key: DBCP-228 URL: https://issues.apache.org/jira/browse/DBCP-228 Project: Commons Dbcp Issue Type: New Feature Reporter: Dain Sundstrom Attachments: ManagedConnection.patch This patch adds support for pooling of ManagedConnections. A managed connection is responsible for managing a database connection in a transactional environment (typically called Container Managed). A managed connection opperates like any other connection when no gloabal transaction (a.k.a. XA transaction or JTA Transaction) is in progress. When a global transaction is active a single physical connection to the database is used by all ManagedConnections accessed in the scope of the transaction. Connection sharing means that all data access during a transaction has a consistent view of the database. When the global transaction is committed or rolled back the enlisted connections are committed or rolled back. This patch supports full XADataSources and non-XA data sources using local transaction semantics. non-XA data sources commit and rollback as part of the transaction but are not recoverable in the case of an error because they do not implement the two-phase commit protocol. The patch includes test cases and javadoc comments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
