quot; 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.
>
He means v2.0 AFAICT. Details [1].
-Rahul
[1] http://jakarta.apache.org/commons/release
Should be fixed now. The nightlies run the m1 build and that needs
the transitive dependencies to be specified. We could change the
nightly to m2, but I think it is a good idea to keep the m1 build
working for now and the nightly can alter us if we break it.
Phil
-
Author: psteitz
Date: Tue Jul 24 21:45:13 2007
New Revision: 559315
URL: http://svn.apache.org/viewvc?view=rev&rev=559315
Log:
Added transitive dependencies needed by m1 build.
Modified:
jakarta/commons/proper/dbcp/trunk/project.xml
Modified: jakarta/commons/proper/dbcp/trunk/project
Yeah, our work CI also found it. Linux box.
On 7/24/07, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
On 7/24/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> Can anyone else reproduce this failure?
>
Yes (XP, Tiger, m102).
-Rahul
> -dain
>
> On Jul 24, 2007, at 3:03 AM, Phil Steitz wrote:
>
> >
On 7/24/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
Can anyone else reproduce this failure?
Yes (XP, Tiger, m102).
-Rahul
-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
>
---
tibility, 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
On 7/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: dain
Date: Mon Jul 23 15:28:37 2007
New Revision: 558884
URL: http://svn.apache.org/viewvc?view=rev&rev=558884
Log:
DBCP-221 Changed BasicDataSource.close() to permanently mark the data source as
closed. At clos
Author: dain
Date: Tue Jul 24 10:48:05 2007
New Revision: 559136
URL: http://svn.apache.org/viewvc?view=rev&rev=559136
Log:
Added note about fix to BasicDataSource.close()
Modified:
jakarta/commons/proper/dbcp/trunk/xdocs/changes.xml
Modified: jakarta/commons/proper/dbcp/trunk/x
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 w
Author: dain
Date: Tue Jul 24 10:35:02 2007
New Revision: 559128
URL: http://svn.apache.org/viewvc?view=rev&rev=559128
Log:
Added change log note on the deprecation of SQLNestedException
Modified:
jakarta/commons/proper/dbcp/trunk/xdocs/changes.xml
Modified: jakarta/commons/proper/
[
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
Author: dain
Date: Tue Jul 24 10:24:03 2007
New Revision: 559119
URL: http://svn.apache.org/viewvc?view=rev&rev=559119
Log:
Deprecated SQLNestedException
Modified:
jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/SQLNestedException.java
Modified:
jakarta/commons/pr
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]
F
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
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]
Author: dain
Date: Mon Jul 23 12:48:39 2007
New Revision: 558845
URL: http://svn.apache.org/viewvc?view=rev&rev=558845
Log:
DBCP-150 added setter for connectionProperties in BasicDataSource
Modified:
jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/BasicDataSource.
Author: dain
Date: Mon Jul 23 12:53:27 2007
New Revision: 558846
URL: http://svn.apache.org/viewvc?view=rev&rev=558846
Log:
DBCP-225 throw an IllegalStateException if connection factory returns a null
connection. This avoids creating DelegatingConnections with a null delegate.
Modi
Author: dain
Date: Mon Jul 23 13:02:19 2007
New Revision: 558850
URL: http://svn.apache.org/viewvc?view=rev&rev=558850
Log:
DBCP-207 only set auto-commit and read-only if the new value would be different
from the current value
Modified:
jakarta/commons/proper/dbcp/trunk/src/java/org/ap
Author: dain
Date: Mon Jul 23 15:28:37 2007
New Revision: 558884
URL: http://svn.apache.org/viewvc?view=rev&rev=558884
Log:
DBCP-221 Changed BasicDataSource.close() to permanently mark the data source as
closed. At close all idle connections are destroyed and the method returns.
As exis
[
https://issues.apache.org/jira/browse/DBCP-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Heuer updated DBCP-191:
---
Attachment: patch.txt
patch against nightly for 23 July 2007, or in other words
$ svn co --revision
[
https://issues.apache.org/jira/browse/DBCP-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514825
]
Michael Heuer commented on DBCP-191:
Attached is a patch that allows commons-dbcp and its tests to compile under
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
[
https://issues.apache.org/jira/browse/DBCP-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dain Sundstrom updated DBCP-143:
Attachment: DBCP-143.patch
This patch replaces:
new SQLNestedException(msg, e);
with
accessToUnderlyingConnectionAllowed flag in ManagedConnection breaks equals,
hashCode and toString
---
Key: DBCP-235
URL: https://issues.apache.org/jira/browse/DBCP
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
[
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
teitz 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).
>> >
>
[
https://issues.apache.org/jira/browse/DBCP-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcos Sanz reopened DBCP-212:
--
Not really fixed. As Phil wrote: "until pool is improved somehow to be more
intelligent about destr
On 7/23/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
When issues are complete, do you close or resolve them? I have been
closing them, but just noticed that may are resolved.
I close em.
Also, should I create a DBCP 1.4 and move the issues (like max time
limit for pooled objects) we
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
[
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
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
[
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
[
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
Sending
2007/7/23, Dain Sundstrom <[EMAIL PROTECTED]>:
When issues are complete, do you close or resolve them? I have been
closing them, but just noticed that may are resolved.
In Tiles, we resolve the issues when the fix is done. We close them
when a release gained a positive vote.
Antonio
[
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
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.
[
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
[
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 a
[
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 p
[
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 connecti
[
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 man
[
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 createDataSou
Author: psteitz
Date: Sun Jul 22 14:19:48 2007
New Revision: 558551
URL: http://svn.apache.org/viewvc?view=rev&rev=558551
Log:
Moved ConfigurationException to performance package
Renamed build.xml, config.xml to *-dbcp
Made peak and min mean load both configurable
Fixed some error
[
https://issues.apache.org/jira/browse/DBCP-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514474
]
Ralf Hauser commented on DBCP-152:
--
Dain,
thx for your explanations.
Unfortunately, it appears that "JS
Author: psteitz
Date: Sat Jul 21 16:53:32 2007
New Revision: 558398
URL: http://svn.apache.org/viewvc?view=rev&rev=558398
Log:
Added missing close.
Modified:
jakarta/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
Modified:
jak
[
https://issues.apache.org/jira/browse/DBCP-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz resolved DBCP-232.
--
Resolution: Fixed
Javadoc fix committed in r558394. Thanks for reporting thi
> maxWait = 0 wa
Author: psteitz
Date: Sat Jul 21 16:46:27 2007
New Revision: 558394
URL: http://svn.apache.org/viewvc?view=rev&rev=558394
Log:
Fixed javadoc to match behavior when BasicDataSource maxWait is 0
(blocks indefinitely).
JIRA: POOL-232
Modified:
jakarta/commons/proper/dbcp/trunk/src/java
mons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
Modified:
jakarta/commons/proper/dbcp/trunk/src/test/org/apache/commons/dbcp/datasources/TestPerUserPoolDataSource.java
URL:
http://svn.apache.org/viewvc/jakarta/commons/proper/dbcp/trunk/src/test
On 7/21/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
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 p
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
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
z 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/db
Author: psteitz
Date: Sat Jul 21 08:52:02 2007
New Revision: 558334
URL: http://svn.apache.org/viewvc?view=rev&rev=558334
Log:
Document change in r558332.
Modified:
jakarta/commons/proper/dbcp/trunk/xdocs/changes.xml
Modified: jakarta/commons/proper/dbcp/trunk/xdocs/changes.xml
URL:
[
https://issues.apache.org/jira/browse/DBCP-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz resolved DBCP-11.
-
Resolution: Fixed
Patch applied. Thanks.
> [dbcp] stmt.getConnection() != Connection used to create
are wrapped with a delegating object, which already properly handle
the back pointers for Connection and Statement. Also added tests to to assure
that the *same* object used to create the statement or result set is returned
from either getConnection() or getStatement().
JIRA: DBCP-11
Patch provide
Author: psteitz
Date: Sat Jul 21 08:44:03 2007
New Revision: 558331
URL: http://svn.apache.org/viewvc?view=rev&rev=558331
Log:
Fixed typo in comment.
Modified:
jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/DelegatingConnection.java
Modified:
jakarta/commons/pr
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:
>
>> On 7/19/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
>>> Are there any DBCP-1.3 release plans? Base
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 th
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 s
[
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
[
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
[
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 som
[
https://issues.apache.org/jira/browse/DBCP-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514358
]
Holger Hoffstätte commented on DBCP-44:
---
Hi Dain, I agree that the evictor thread is problematic (it should go
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
[
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
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
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
[
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 t
I've moved this issue over to the Torque JIRA project, rather than
closing and asking the user to open one there.
Hen
On 7/20/07, Henri Yandell (JIRA) <[EMAIL PROTECTED]> wrote:
[
https://issues.apache.org/jira/browse/DBCP-53?page=com.atlassian.jira.plugin.system.issueta
[
https://issues.apache.org/jira/browse/DBCP-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated DBCP-53:
--
Summary: 'not supported' error given against Firebird DB (was: [dbcp]
commons dbcp does no
[
https://issues.apache.org/jira/browse/DBCP-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514130
]
Ralf Hauser commented on DBCP-152:
--
Allowing for a non-global SSL socket factory has nothing to do with mysql. Even
[
https://issues.apache.org/jira/browse/DBCP-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514125
]
Ralf Hauser commented on DBCP-155:
--
I certainly agree that you should not break the standards. However, if you can
tion 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
>
ments 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 wer
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
On 7/19/07, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
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 th
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
[
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
[
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 : set
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 n
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 P
[
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
[
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
[
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
[
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
[
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
[
https://issues.apache.org/jira/browse/DBCP-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz resolved DBCP-209.
--
Resolution: Invalid
I agree with Dain. For BasicDataSource, the username and password are pool
[
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 configurati
[
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
Author: psteitz
Date: Wed Jul 18 21:22:23 2007
New Revision: 557488
URL: http://svn.apache.org/viewvc?view=rev&rev=557488
Log:
Added other boogs slain in r557176.
Modified:
jakarta/commons/proper/dbcp/trunk/xdocs/changes.xml
Modified: jakarta/commons/proper/dbcp/trunk/xdocs/changes.xml
[
https://issues.apache.org/jira/browse/DBCP-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz resolved DBCP-23.
-
Resolution: Fixed
Fixed in r 557176.
> [dbcp] SQLException When PoolablePreparedStatement Already Clo
[
https://issues.apache.org/jira/browse/DBCP-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz resolved DBCP-5.
Resolution: Fixed
Fixed in r 557176.
> [dbcp] PoolGuardConnectionWrapper violates close() contr
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
[
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
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
[
https://issues.apache.org/jira/browse/DBCP-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz resolved DBCP-3.
Resolution: Fixed
Fixed in r 557176.
> [dbcp] PoolableConnection.close() won't allow multip
[
https://issues.apache.org/jira/browse/DBCP-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz resolved DBCP-134.
--
Resolution: Fixed
Fixed in r 557176.
> [dbcp] DelegatingConnection.close() throws except
[
https://issues.apache.org/jira/browse/DBCP-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz resolved DBCP-233.
--
Resolution: Fixed
Patch applied. Many thanks.
> Allow connection, statement, and result set to
the resource is closed and any subsequent calls have no effect.
This behavior is required as per the JavaDocs for these classes. Also added
tests for closing all types multiple times and updated any tests that
incorrectly assert that a resource can not be closed more then once.
JIRA: DBCP-233
Patch prov
1 - 100 of 1878 matches
Mail list logo
