Re: [nightly build] dbcp failed.
Can anyone else reproduce this failure? -dain On Jul 24, 2007, at 3:03 AM, Phil Steitz wrote: Failed build logs: http://vmbuild.apache.org/~commons/nightly/logs//20070724/dbcp.log - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[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]
Re: [DBCP] Remove SQLNestedException
On Jul 24, 2007, at 7:56 AM, Phil Steitz wrote: On 7/23/07, Dain Sundstrom [EMAIL PROTECTED] wrote: DBCP-143 talks about problem with propagation of SQLNestedException to clients and the comment suggests a conversion to normal Java nested exception when we switch to Java 1.4. Since we made the leap, I did a bit of refactoring to remove this exception class. Basically I replace: new SQLNestedException(msg, e); with: (SQLException) new SQLException(msg).initCause(e); I attached this at a patch to 143 as I'm not 100% sure we want to go this direction. So, should we drop SQLNestedException? This is tempting, but it breaks backward compatibility, so we should probably deprecate in 1.3 and remove in the next major release. I guess the deprecation warning / release notes should just tell people to remove legacy casts in client code, since we never advertise this exception. Sounds good. I marked the class as deprecated, moved DBCP-143 to 1.4, and added a note to the change log. -dain - 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]
[DBCP] JIRA workflow?
When issues are complete, do you close or resolve them? I have been closing them, but just noticed that may are resolved. Also, should I create a DBCP 1.4 and move the issues (like max time limit for pooled objects) we aren't going to get to for 1.3 over. -dain - 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]
Re: [DBCP] DBCP-44 Deadlock
On Jul 20, 2007, at 5:26 PM, Phil Steitz wrote: On 7/20/07, Dain Sundstrom [EMAIL PROTECTED] wrote: On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote: On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote: I would love to have a fix for DBCP-44; but that could wait on pool 1.4 if necessary (and Ipersonally see no way to fix it just within dbcp. It would be great if I was wrong on that). I think the makeObject method is over synchronized. Actually, the class doesn't look it's synchronized properly at all. I'll take a shot at fixing this. I attached a patch that fixes the synchronization in PoolableConnectionFactory, but the deadlock still persists. The problem is GenericObjectPool.borrowObject() is synchronized so when it needs to makeObject that method is called while the synchronized block is held. I think this would take major surgery to make GenericObjectPool not perform this way. Thats what I feared. Thanks for looking in any case. Should I commit the patch that removes the excessive synchronization from PoolableConnectionFactory. It won't fix this problem but may alleviate some other ones. -dain - 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]
Re: [DBCP] close issues
On Jul 21, 2007, at 12:35 PM, Phil Steitz wrote: Its not quite that bad now; but the returning orphans do not get closed on return. What happens now is that the GOP throws IllegalStateException when you try to return an object (or perform any other operation) on a closed pool. We could include a patch in pool 1.3.1 to passivate and destroy a returning orphan before throwing the IllegalStateException, taking a baby step toward better lifeclycle management. Since the pool does not hold references to these orphans once its closed, I am not sure how big a problem this is in general; though certainly for dbcp, the underlying physical connections do not get closed right away in this case. I implemented the IllegalStateException idea. Now when close is called on BasicDataSource, it is marked as close and no new connections will be created (you get a SQLException). As before the idle connections are immedately destroyed and the close method returns. As the active connections are closed, they are destroyed. -dain - 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]
[DBCP] Remove SQLNestedException
DBCP-143 talks about problem with propagation of SQLNestedException to clients and the comment suggests a conversion to normal Java nested exception when we switch to Java 1.4. Since we made the leap, I did a bit of refactoring to remove this exception class. Basically I replace: new SQLNestedException(msg, e); with: (SQLException) new SQLException(msg).initCause(e); I attached this at a patch to 143 as I'm not 100% sure we want to go this direction. So, should we drop SQLNestedException? -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] close issues
On Jul 20, 2007, at 10:15 PM, Phil Steitz wrote: On 7/20/07, Dain Sundstrom [EMAIL PROTECTED] wrote: On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote: I think this will require a patch to pooling (documented in DBCP-221). What are the plans for pooling? This is a tiny change so we could do a pool 1.3.1 or 1.4 release. Alternatively, we could wait until DBCP 1.4 (and the next pool release) to address this issue. I am fine waiting to DBCP 1.4, since unless we are talking about different things, this really amounts to a significant change to both dbcp and pool. If what we want is to *always* track open connections and have the lingering close apply to the active (i.e. checked out) as well as idle connections, we need to follow through on what looks like it was the original plan of moving AbandonedObjectPool to pool and use this _all the time_ in place of GenericObjectPool, which is really just an idle object pool (maintains no references to borrowed objects). I think there are two features here also. The first is a lingering close where we close the data source along with all idle connection. Then as the checked out connections are returned to the pool, we destroy them instead of putting them in a closed pool. The second feature is a force close which as you pointed out requires tracking of active connection. After looking at the pooling code, I think that will take a lot of work to implement with the current code. In any case, we need to get a pool release out ASAP since pool 1.3 introduced some bugs that are causing problems (see for example POOL-97) since dbcp started using this version. Synchronization was increased in pool 1.3 as well. The hang here is lack of volunteer time and difficulty getting into the codebase. I have only recently started working on the pool code base. The compositepool package includes an alternative impl that we have been thinking about as a pool 2.0. The plan that I proposed a while back (http://www.mail-archive.com/commons-dev@jakarta.apache.org/ msg94027.html) was to push out a pool 1.3.1 patch release fixing POOL-97 (when reviewing the patch there, remember that dbcp statement pooling can create quite a few pools) and other bugs fixed since 1.3 and have DBCP 1.3 depend on that, both fully backward compatible with current versions. I still think we should do that. I can handle the RM duty for both of these and close a couple more of the pool bugs, but what we need to speed things up is more eyeballs validating and testing and contributing - and applying - patches. I'll try to review the patch. If we do do a 1.3.1, I think we should change GOP and GKOP to destroy objects returned to the pool after the pool is closed. Otherwise you end up with stuck objects in a closed pool. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] DBCP-44 Deadlock
On Jul 20, 2007, at 5:26 PM, Phil Steitz wrote: On 7/20/07, Dain Sundstrom [EMAIL PROTECTED] wrote: On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote: On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote: I would love to have a fix for DBCP-44; but that could wait on pool 1.4 if necessary (and Ipersonally see no way to fix it just within dbcp. It would be great if I was wrong on that). I think the makeObject method is over synchronized. Actually, the class doesn't look it's synchronized properly at all. I'll take a shot at fixing this. I attached a patch that fixes the synchronization in PoolableConnectionFactory, but the deadlock still persists. The problem is GenericObjectPool.borrowObject() is synchronized so when it needs to makeObject that method is called while the synchronized block is held. I think this would take major surgery to make GenericObjectPool not perform this way. Thats what I feared. Thanks for looking in any case. I think the way to solve this is to write a new pool implementation that is much more async. This easier with the Java5 concurrent packages, but still quite tricky. Yes, and at least for dbcp 1.3, I would prefer not to hop all the way to 1.5 required JDK level. I agree. I also wouldn't want to switch dbcp to a pool that hasn't been heavily tested first. I'll attempt to put together one in a few days. Regardless, I don't think this is something we should target for this release. Before writing another one, have a look at the compositepool package in pool head. Well, I got this email after hacking on one for about 6 hours. I the kind of person that needs to finish things I start, so I'm going to keep hacking on it. I will take a look at composite pool in 2.0 and assuming my version doesn't suck. I'll see if I can merge any of my good features into that code. In the end I may just end up wasting a lot of my time, but at least I'll learn how hard it is to write a good pool:) -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r557176 - in /jakarta/commons/proper/dbcp/trunk: src/java/org/apache/commons/dbcp/ src/java/org/apache/commons/dbcp/cpdsadapter/ src/test/org/apache/commons/dbcp/ src/test/org/apache/c
I think passivate() is called automatically when the connection is
put back in the pool (due to the _conn.close() call). I think there
are tests that check that the statements were closed when the
connection is closed.
Anyway, I don't think it is a big deal to call passivate twice. It
used to cause a SQLException because the delegating statements would
throw an exception on the second close.
-dain
On Jul 19, 2007, at 10:33 PM, Phil Steitz wrote:
Sorry I missed this in initial review. I am not sure we want to
remove the passivate() below, since that closes statements traced by
this connection. Am I missing something here?
Phil
jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/
DelegatingConnection.java
Tue Jul 17 23:46:16 2007
@@ -208,10 +208,17 @@
* Closes the underlying connection, and close
* any Statements that were not explicitly closed.
*/
-public void close() throws SQLException
-{
-passivate();
-_conn.close();
+public void close() throws SQLException {
+// close can be called multiple times, but
PoolableConnection improperly
+// throws an exception when a connection is closed twice,
so before calling
+// close we aren't alreayd closed
+if (!isClosed()) {
+try {
+_conn.close();
+} finally {
+_closed = true;
+}
+}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
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]
[DBCP] JIRAs [was: Release 1.3 soon?]
On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote: Here are some open JIRAs I think we can close: Fixed: DBCP-194 BasicDataSource.setLogWriter should not do createDataSource DBCP-102 setReadOnly setAutoCommit called too many times DBCP-97 setAutoCommit(true) when returning connection to the pool DBCP-212 PoolingDataSource closes physical connections +1 and thanks for verifying 97. Invalid: DBCP-209 Is DataSource.getConnection(user, pass) working the way it is suppose to? User should be using either SharedPoolDataSource or the PerUserPoolDataSource. DBCP-53 commons dbcp does not supports Firebird DB Torque bug or misconfiguration by user. +1 Won't fix DBCP-115 allow to set = 6 parameters to do non-global SSL Request for mysql specific feature DBCP-152 add a socketFactory attribute to BasicDataSource (to allow SSL thread-safe) Request for mysql specific feature +1 If you grant me DBCP JIRA karma, I can make these changes myself. I'm a JIRA admin, so you just need to grant me karma here (email) and I can add the permission to JIRA myself. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Release 1.3 soon?
On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote: On 7/19/07, Dain Sundstrom [EMAIL PROTECTED] wrote: Are there any DBCP-1.3 release plans? Based on the JIRAs I think we are close to being ready to release. Are there any items that are planned but don't have JIRAs? There are two things that I would like to at least talk about that relate to various JIRAs and comments on the list: 1) Intended current and future contract of close() on a connection pool, in particular the contract of BasicDataSource.close. The javadoc says Close and release all connections that are currently stored in the connection pool associated with our data source. Some users interpret this - incorrectly - to mean that close will close *active* as well as idle connections. Even when AbandonedConfig is used (in which case the pool holds references to connections that have been checked out), close only closes idle connections (since the pool is really and idle object pool). So the answer to the question in, e.g. DBCP-221, is sorry, no way to do that. Javadoc should be improved in any case. 2) Immutable-once-initialized status of BasicDataSource. I am inclined to closeDBCP-221 as WONTFIX, but in this case we should rip out the remnants of what must have seemed like a good idea at the time to support restart. This is sort of related to 1), because if we are going to attempt to allow BasicDataSource to be mutable once it has been initialized, I don't see any way to do that consistently without closing or appropriately modifying connections that have been checked out. Since we don't do that now, we can't really support this. My vote would be to keep BasicDataSource immutable-once-initialized. I think these are basically the same issue. I agree with the comments in DBCP-221 which seems to want a lingering close. This is in line with how I expect close to work (having not read any of the pooling code yet). I think the root of this problem is we don't have a clear start/stop life-cycle methods. Currently, we are using the first getConnection () for start and close() for stop, which I think are good choices. Maybe we could keep those choices, and introduce an explicit start(), stop() and stop(long maxWait). This way we can support the close lingering and close immediately options people seem to be asking for. Once we have this functionality, it should be easy to add restart() which would close() lingering the existing inner datasource and create/start a new one. I'm not sure this is something that can be done without changes to pool, but I'll take a look at it today. snip/ I would love to have a fix for DBCP-44; but that could wait on pool 1.4 if necessary (and Ipersonally see no way to fix it just within dbcp. It would be great if I was wrong on that). I think the makeObject method is over synchronized. Actually, the class doesn't look it's synchronized properly at all. I'll take a shot at fixing this. We should also address DBCP-4 (by using jdk logging, since we have bumped to 1.4 level). I think it would be good to start adding some simple instrumentation in 1.3 that we could add to in subsequent releases. Having things like physical connection opens / closes, pool high water marks, waits, etc., loggable would make debuggng and performance tuning much easier. In the future, I'd like these events to be available via a listener interface, so I can write monitoring code (like an mbean). Of course working out that interface takes time, so I think we should add the logging in 1.3 and a listener in 1.4. Are there any notes on how we'd like to use util.Logging (log names, levels, etc.)? I will finish reviewing recent patches tomorrow and come up with a straw man release plan this weekend if no one beats me to it. I'll look at DBCP-44 since I think it is an easy small fix. Then the close() issue and finally logging, unless someone beats me to them. BTW, it is getting challenging to write new patches with the current patches I have out. I have been trying to keep patches so there aren't file overlaps. I may need to start putting ordering information into the patches like apply after DBCP-1234. Thanks for all of your help on this, Dain. No prob. This code is like programming crack for me Small tasks for a big programming high :) -dain - 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
Re: [DBCP] DBCP-44 Deadlock
On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote: On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote: I would love to have a fix for DBCP-44; but that could wait on pool 1.4 if necessary (and Ipersonally see no way to fix it just within dbcp. It would be great if I was wrong on that). I think the makeObject method is over synchronized. Actually, the class doesn't look it's synchronized properly at all. I'll take a shot at fixing this. I attached a patch that fixes the synchronization in PoolableConnectionFactory, but the deadlock still persists. The problem is GenericObjectPool.borrowObject() is synchronized so when it needs to makeObject that method is called while the synchronized block is held. I think this would take major surgery to make GenericObjectPool not perform this way. I think the way to solve this is to write a new pool implementation that is much more async. This easier with the Java5 concurrent packages, but still quite tricky. I'll attempt to put together one in a few days. Regardless, I don't think this is something we should target for this release. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[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
[DBCP] close issues
On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote: On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote: On 7/19/07, Dain Sundstrom [EMAIL PROTECTED] wrote: Are there any DBCP-1.3 release plans? Based on the JIRAs I think we are close to being ready to release. Are there any items that are planned but don't have JIRAs? There are two things that I would like to at least talk about that relate to various JIRAs and comments on the list: 1) Intended current and future contract of close() on a connection pool, in particular the contract of BasicDataSource.close. The javadoc says Close and release all connections that are currently stored in the connection pool associated with our data source. Some users interpret this - incorrectly - to mean that close will close *active* as well as idle connections. Even when AbandonedConfig is used (in which case the pool holds references to connections that have been checked out), close only closes idle connections (since the pool is really and idle object pool). So the answer to the question in, e.g. DBCP-221, is sorry, no way to do that. Javadoc should be improved in any case. 2) Immutable-once-initialized status of BasicDataSource. I am inclined to closeDBCP-221 as WONTFIX, but in this case we should rip out the remnants of what must have seemed like a good idea at the time to support restart. This is sort of related to 1), because if we are going to attempt to allow BasicDataSource to be mutable once it has been initialized, I don't see any way to do that consistently without closing or appropriately modifying connections that have been checked out. Since we don't do that now, we can't really support this. My vote would be to keep BasicDataSource immutable-once-initialized. I think these are basically the same issue. I agree with the comments in DBCP-221 which seems to want a lingering close. This is in line with how I expect close to work (having not read any of the pooling code yet). I think the root of this problem is we don't have a clear start/ stop life-cycle methods. Currently, we are using the first getConnection() for start and close() for stop, which I think are good choices. Maybe we could keep those choices, and introduce an explicit start(), stop() and stop(long maxWait). This way we can support the close lingering and close immediately options people seem to be asking for. Once we have this functionality, it should be easy to add restart() which would close() lingering the existing inner datasource and create/start a new one. I'm not sure this is something that can be done without changes to pool, but I'll take a look at it today. I think this will require a patch to pooling (documented in DBCP-221). What are the plans for pooling? This is a tiny change so we could do a pool 1.3.1 or 1.4 release. Alternatively, we could wait until DBCP 1.4 (and the next pool release) to address this issue. I did attach a patch to DBCP-221 that stops BasicDataSource from recreating the inner PoolingDataSource once close has been called. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[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]
[DBCP] Remove primitive default values?
The PerUserDataSource and SharedPoolDataSource use primitives for the read only, transaction isolation and auto commit default values so there is not way to see if the value was set in the configuration. This means there is no way to allow the driver defaults to pass through like in the PoolingDataSource. In the future, should all of these default values be non-primitive so we do not set them unless explicitly set in the configuration? -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DBCP] Release 1.3 soon?
Are there any DBCP-1.3 release plans? Based on the JIRAs I think we are close to being ready to release. Are there any items that are planned but don't have JIRAs? -dain Here are some open JIRAs I think we can close: Fixed: DBCP-194 BasicDataSource.setLogWriter should not do createDataSource DBCP-102 setReadOnly setAutoCommit called too many times DBCP-97 setAutoCommit(true) when returning connection to the pool DBCP-212 PoolingDataSource closes physical connections Invalid: DBCP-209 Is DataSource.getConnection(user, pass) working the way it is suppose to? User should be using either SharedPoolDataSource or the PerUserPoolDataSource. DBCP-53 commons dbcp does not supports Firebird DB Torque bug or misconfiguration by user. Won't fix DBCP-115 allow to set = 6 parameters to do non-global SSL Request for mysql specific feature DBCP-152 add a socketFactory attribute to BasicDataSource (to allow SSL thread-safe) Request for mysql specific feature - 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]
[DBCP] More duplicate close JIRAs to close
I believe the duplicate close fix also addresses these JIRAs: DBCP-5 PoolGuardConnectionWrapper violates close() contract DBCP-23 SQLException When PoolablePreparedStatement Already Closed -dain - 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]
Re: [DBCP] Back pointers
Sounds good to me. I attached my fix to DBCP-11. 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(). Note we must make sure to update this test for each release of the JDBC spec we support as new ways of obtaining these objects tend to be added over time. As per your suggestion below, this patch does not fix back pointers in connections obtained from a InstanceKeyDataSource using the cpdsadapter. The cpdsadapter does not use the delegating wrapper internally, and will need a different solution. DBCP-217 should also be closed. -dain On Jul 17, 2007, at 9:39 PM, Phil Steitz wrote: On 7/17/07, Dain Sundstrom [EMAIL PROTECTED] wrote: I'm working on a fix for the back pointers bugs DBCP-11 and DBCP-217 where the Statement.getConnection() and ResultSet.getStatement() return the wrong objects. The fix is pretty simple; we just need to make sure we wrap Statements and ResultSets returned from DelegatingConnection with the matching delegating type. +1 Anyway, I have the fix mostly complete with a bunch of test cases, but there is one problem... The PerUserPoolDataSource and SharedPoolDataSource classes return the ConnectionImpl class directly. This class is a wrapper around the real connection so we need to wrap returned Statements which is easy enough. The problem is these datasources use the CPDSConnectionFactory which does not call passivate on the delegating connection when the connection is returned to the pool so the Statements owned by the DelegatingConnection aren't closed. To make matters worse, CPDSConnectionFactory can't call passivate anyway because it is in a different package and the method is protected :( At this point I'm not sure what to do. I could fix the problem for all DataSources except for these two, and in the future we could rework these two to subclass PoolingDataSource. Alternative, we could move CPDSConnectionFactory to same package as DelegatingConnection or make is a sublcass of some ConnectionFactory with access to the passivate method. I really do think these datasources should be brought in line with the main abstractions used by the other classes, but I don't think that is something for this release (maybe for 2.0?). I think we should leave this alone for now and consider refactoring for 2.0, but there is a semantic difference that we need to keep in mind. InstanceKeyDataSource (parent of PerUser and SharedPool) sources connections from a ConnectionPoolDataSource. These datasources return connection *handles* (PooledConnection impls), which are not the same as DelegatingConnections. The cpdsadapter package is just there for older jdbc drivers that do not provide ConnectionPoolDataSource implementations. See the javadoc for InstanceKeyDataSource and also the implementation of makeObject there. The key difference in the contract is that InstanceKeyDataSource implements ConnectionEventListener, so when used with a driver that correctly supports ConnectionPoolDataSource, the connection handles handed out to users notify the pool (actually the factory in dbcp) when they are closed by the user. See connectionClosed in CPDSConnectionFactory. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DBCP] Back pointers
I'm working on a fix for the back pointers bugs DBCP-11 and DBCP-217 where the Statement.getConnection() and ResultSet.getStatement() return the wrong objects. The fix is pretty simple; we just need to make sure we wrap Statements and ResultSets returned from DelegatingConnection with the matching delegating type. Anyway, I have the fix mostly complete with a bunch of test cases, but there is one problem... The PerUserPoolDataSource and SharedPoolDataSource classes return the ConnectionImpl class directly. This class is a wrapper around the real connection so we need to wrap returned Statements which is easy enough. The problem is these datasources use the CPDSConnectionFactory which does not call passivate on the delegating connection when the connection is returned to the pool so the Statements owned by the DelegatingConnection aren't closed. To make matters worse, CPDSConnectionFactory can't call passivate anyway because it is in a different package and the method is protected :( At this point I'm not sure what to do. I could fix the problem for all DataSources except for these two, and in the future we could rework these two to subclass PoolingDataSource. Alternative, we could move CPDSConnectionFactory to same package as DelegatingConnection or make is a sublcass of some ConnectionFactory with access to the passivate method. I really do think these datasources should be brought in line with the main abstractions used by the other classes, but I don't think that is something for this release (maybe for 2.0?). Suggestion? -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Back pointers
BTW the reason we are getting ConnectionImpls instead of raw connections from the PooledDataSource is because PooledConnectionImpl.getConnection():159 wraps the raw connection with a ConnectionImpl. The line of code is commented with the spec requires that this return a new Connection instance. If we didn't wrap, the back pointers would work, but we'd be violating the JDBC spec. Once we wrap, we need to wrap all the statements and result sets so the back pointers are valid. Another bug, is we're not tracking statements and result sets, so when the logical connection is closed the statements and result sets are not closed as required buy the spec. -dain On Jul 17, 2007, at 2:42 PM, Dain Sundstrom wrote: I'm working on a fix for the back pointers bugs DBCP-11 and DBCP-217 where the Statement.getConnection() and ResultSet.getStatement() return the wrong objects. The fix is pretty simple; we just need to make sure we wrap Statements and ResultSets returned from DelegatingConnection with the matching delegating type. Anyway, I have the fix mostly complete with a bunch of test cases, but there is one problem... The PerUserPoolDataSource and SharedPoolDataSource classes return the ConnectionImpl class directly. This class is a wrapper around the real connection so we need to wrap returned Statements which is easy enough. The problem is these datasources use the CPDSConnectionFactory which does not call passivate on the delegating connection when the connection is returned to the pool so the Statements owned by the DelegatingConnection aren't closed. To make matters worse, CPDSConnectionFactory can't call passivate anyway because it is in a different package and the method is protected :( At this point I'm not sure what to do. I could fix the problem for all DataSources except for these two, and in the future we could rework these two to subclass PoolingDataSource. Alternative, we could move CPDSConnectionFactory to same package as DelegatingConnection or make is a sublcass of some ConnectionFactory with access to the passivate method. I really do think these datasources should be brought in line with the main abstractions used by the other classes, but I don't think that is something for this release (maybe for 2.0?). Suggestion? -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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]
Re: Maven2 snapshot repo?
On Jul 13, 2007, at 11:17 PM, Henri Yandell wrote: On 7/13/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Dain Sundstrom wrote: Are snapshot jars for commons (specifically commons-dbcp) published anywhere? I expected to see them here http://people.apache.org/repo/m2-snapshot-repository/ Almost none of the commons components use Maven 2 to build or publish their jar-files. So you won't find many commons-snapshots in the directory you mention. There is however a nightly-build script that runs and creates snapshots of all commons components, using their preferred build system (Ant, Maven 1 or Maven 2). You can find the artifacts it produces here: http://vmbuild.apache.org/~commons/nightly/builds/ Or as a legacy maven-1 repository: http://vmbuild.apache.org/~commons/nightly/maven/ The aim being to get them back into http://people.apache.org/repo/m1-snapshot-repository/ at some point. mvn deploy worked for publishing it to http://people.apache.org/ repo/m2-snapshot-repository/commons-dbcp/commons-dbcp/1.3-SNAPSHOT/ -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r555980 - in /jakarta/commons/proper/dbcp/trunk: src/java/org/apache/commons/dbcp/ src/java/org/apache/commons/dbcp/managed/ xdocs/
Thanks for applying the patch and thanks for fixing my terrible spelling :) -dain On Jul 13, 2007, at 6:25 AM, Phil Steitz wrote: On 7/13/07, Julien Aymé [EMAIL PROTECTED] wrote: It seems good; just a little mispelling problem with the protected method createConectionFactory(): Wouldn't it be better if it were spelled createConnectionFactory() ? (With 2 n in connection :-) Good catch. Thanks! Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven2 snapshot repo?
Are snapshot jars for commons (specifically commons-dbcp) published anywhere? I expected to see them here http://people.apache.org/repo/ m2-snapshot-repository/ -dain - 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]
Re: [DBCP] Managed Connection support
On Jul 5, 2007, at 7:13 AM, Phil Steitz wrote: Thanks, Dain. I applied the patch. I also patched the m1 and ant builds to work. The Ant now fails with JDK 1.3, but unless someone screams loudly soon, we have moved the minimum jdk level for dbcp 1.3 to JDK 1.4 (per earlier discussion), so this is not an issue. Sweet! That was very fast. snip/ For now the code is contained in the org.apache.commons.dbcp.managed package, but I would suspect we may want to spread it out amongst the existing packages instead of creating a feature specific package. I'm also not sure what additional interfaces people may want such as equivalents of the BasicDataSource or BasicDataSourceFactory. I am ambivalent on the merging into existing packages, but we should talk about this. We can figure that out as we get close to a release. If the thing isn't fully tested by then we could just mark the whole package as experimental. The code has tests and has javadoc, but it needs real world testing and some real docs. I'm going try hooking it into OpenEJB and running it's massive test suite with a couple of opensource DBs. Anyways, I hope you all like it and accept the patch. I'm around to help with changes or whatever. I also ran into a few bugs while working on this that are already reported in JIRA (like the close bugs) and am willing to help with those also. That would be greatly appreciated. We really need [dbcp] and [pool] volunteers. Given that you are an ASF committer, all you have to do is ask to get commons karma and you are certainly welcome to do that :) Excellent, I definitely like access, so I can fix any bugs in the code directly. In [dbcp] 1.3, we can fix the close semantics and other things that involve semantic changes. All suggestions and patches are welcome. I'll take a look at it when I get back in town next week. Thanks again, -dain - 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]
Re: [collections] new snapshot to ibiblio
On May 13, 2004, at 8:39 PM, Mark R. Diggory wrote: There is a convergence between the Gump Integration and this unstable repository which I hope is occurring, eventually, we hope that Gump will be used to produce a nightly build repository for projects, and that most projects will start taking advantage of this Continuous Integration for their development. I have been watching (lurking?) the Gump folks diligently working on this and I think its coming along. I think that implying that Gump will be used by every project is a bit ivory tower. The reality is some projects simply don't want or need continuous integration. Also, Gump is not the only continuous integration system in opensource. I am very concerned that about linking access to SNAPSHOTs to the use of a continuous integration system. Until this is complete, the unstable repository is available for those who need to release unstable builds. Because it is on cvs.apache.org, it is not mirrored, nor does it endup at ibiblio. This unstable repository should not be utilized by non-apache developers, eventually, we may consider some form of security to restrict access to it. This is a no go for geronimo. There are 3 other projects outside of apache that use geronimo snapshots and geronimo in return imports the snapshots from these other projects in to the final assembly. If snapshot access were turned off, our entire build system would stop to work. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
On May 13, 2004, at 2:23 PM, Stephen Colebourne wrote: I am opposed to adding snapshots to ibiblio, as I have seen it create isues. IMHO ibiblio should be released/stable code only. Can you be more clear? I think ibiblio snapshots are great and would hate to see them go away. Think of all the projects out there that are using apache snapshots that would have to add the apache repo to their project. Not only is this a lot of traffic to apache, I think it also sets a bad precedent for other projects. Think of a project using a lot of snapshots and they have to add every small project's repo to the repo list (which may also add to the apache traffic as maven has no idea which repo may have the snapshot, so it tries them all in order) Anyway I'm rambling now I am curious about the issues this creates. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] new snapshot to ibiblio
On May 13, 2004, at 5:44 PM, Noel J. Bergman wrote: I understand the desire to not having projects use snapshots, but the reality is you just sometimes need to build against head. The geronimo team tries to limit snapshots to projects that do instep releases with geronimo but that is still about 30 modules spread across 4 projects. Why use snapshots? If you want to track *current* status, you really want to turn that over to GUMP, which will pull source for every project you depend upon, and build Geronimo and all dependents from source. GUMP is the ASF's Continous Integration project, and will be adding (AIUI) testing, as well as the ability to freeze a given dependent to a released JAR. Again I understand the desire, but I think it is unreasonable to assume everyone will be using GUMP or more generally be using a continuous integration system. In the case of Geronimo, I personally build Geronimo, OpenEJB and TranQL on my machine, so I can do cross project refactoring. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] library management
On May 5, 2004, at 2:20 PM, robert burrell donkin wrote: On 4 May 2004, at 23:52, Simon Kitching wrote: snip I don't understand why the Geronimo team are concerned about large jar files considering they are building a server environment; nevertheless it appears that they are. So I'm willing to give it a stab. (from what dain said earlier) i believe that one aim of geronimo is to create a small application server capable of being embedded. Exactly. There is no reason for a J2EE server to be huge, after all it is just a framework. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Size and scope issues
I can say that it is not politics for the Geronimo project. Our goal is to keep our stand alone kernel small (under 4mb) and a full Geronimo server under 16mb (I'm shooting for under 8). Small size is important as it directly effects the places where people will be using the server. There is a demand for J2EE servers in small hardware. Anyway, just taking a quick look at ibiblio this is the history of commons-collections commons-collections-1.0.jar84k commons-collections-2.0.jar88k commons-collections-2.1.jar 161k commons-collections-3.0.jar 506k commons-collections-SNAPSHOT.jar 842k I find it hard to believe that there are almost 1mb of truly common collections. Either way, the writing is on the wall, the package is growing and growing quickly. Not only that, since this library is widely used in commons, all of those projects are growing at a rapid rate. Building small tight code is not easy, especially as Craig put it the other day perceptions of 'really common' versus 'rarely used' seem to be awfully personal. The alternative is you end up with huge highly-coupled libraries and no one wants to use them anymore. Instead of just bitching, I'll suggest a possible solution. Pick someone in your project who understands the issues, has shown an interest in these problems, and give them the authority to make decisions. I know it is not very Apache, but I believe it will work. -dain /* * Dain Sundstrom * Partner * Core Developers Network */ On May 3, 2004, at 2:11 AM, robert burrell donkin wrote: i definitely agree that one jar is the best solution for many users. for those users for whom jar size is a big issue, then i'd say for that for many use cases rolling a custom version (possibly repackaged) is the best approach. (i have heard that this is how BEA re-uses the commons logging stuff.) but we've been hearing that for some users - many of them influential open source developers - this approach is unsatisfactory. one of the main aims for jakarta commons was to facilitate re-use of library code between open source projects. there are a few of ASF projects who are refusing to use any jakarta commons components on principle now for this reason. (they want small, tight libraries.) i suspect that this is partly political but there is a kernel of truth in the criticisms. it's best to think about this kind of issue early before a momentum develops. certainly, i'm keen to see digester 2 (if and when it comes along) factored into a small core with minimal dependencies together with optional extensions. the binary distribution would contain both a single complete jar and a set of multiple jars. i hope that this should be able to satisfy most users and since this is just a build issue, i suspect that the maintenance would be minimal. - robert On 3 May 2004, at 00:41, Stephen Colebourne wrote: So what problem are we solving? Adding extra jar files alongside the complete built one creates classpath problems for users, an old version of the 'all' jar overriding a later version of the 'part' jar or vice versa. General chaos and confusion. People so have the ability to build their own jar files with just the classes they need. Oh, and I'd also suggest that more jar files does involve more work (maintaining and releasing), and there's a distinct lack of active committers on collections as it is ;-) Stephen On 24 Apr 2004, at 04:33, Craig R. McClanahan wrote: A neat ideal, but perceptions of really common versus rarely used seem to be awfully personal. Kinda reminds me of earlier commons-dev discussions trying to create a commons core JAR that included all of the really common commons JARs, and none of the others. Needless to say, there was no consensus on what the contents should be :-). From: robert burrell donkin [EMAIL PROTECTED] i wonder whether it might be possible to separate out a core jar containing just the basic interfaces and then split the implementations into several themed jars. i still think that this should be in addition to releasing a single jar containing everything, though. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Size and scope issues
On Apr 22, 2004, at 2:40 PM, Michael Heuer wrote: Perhaps some of the classes in [collections] could be presented as a JSR for inclusion in the JDK at some later date. That might cut the size of the jar some. :) All kidding aside, I like this idea. How about starting by splitting collections into, really common collections, and the rarely used collections. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons server infrastructure proposal
On Apr 12, 2004, at 3:43 PM, Mladen Turk wrote: From a chat with the Geronimo team today: The Geronimo contains an IOC (dependency injection) micro-kernel which provides only basic wiring of services and life cycle management. Are the guys willing to pull that out, No, but it is isolated and will be published as a standalone jar. and what's most important do they feel it's a reusable enough for a clustered session replicator or a IPv6 reverse proxy ssl server for example? There is already a clustering project that is (or will be shortly) using this code. As for a reverse proxy, maybe. It would depend on having an http protocol implementation, which we don't, but I do expect to have people create an ejb reverse proxy server (think of a web load balancer, but dealing with ejb requests instead). So, I'm not saying that there isn't a lot of code and most importantly the knowledge around, but you must agree that there is some redundancy among them. The trick is to find them, and hopefully they will be used if found adequate. I'm not saying that I found the holy grail that could both fit geronimo tomcat and avalon, or that it'll ever gonna be used in any of them, but IMHO that's the case with any commons project. IMHO that is the problem I have with most commons projects. They tend to be generalized with out any specific use case, so the bloat. Also take a look at a simple things like a uri or cookie parsing. httpclient, tomcat, geronimo and others has it's own implementations although they are all dealing with the same RFC. We use JDK 1.4 uri parsing and we don't deal with cookie parsing, as http is provided by Jetty (and yes eventually tomcat). If you don't build a commons for such a things, each new project will have to make it's own implementation. That is a good argument, but in geronimo we tend to avoid stuff from jakarta commons as the modules tend to be highly coupled, so if I only want one jar I end up getting 11 mbs of jars. Now don't get me wrong, I like common libraries, but they need to be highly decoupled, tight and address truly common complex problems (if something is trivial or not common, I'll just copy the code in). -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
