You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kristian Waagan (JIRA)" <ji...@apache.org> on 2008/02/19 11:12:43 UTC
[jira] Created: (DERBY-3431) DatabaseMetaData.getConnection returns
the wrong connection when using connection pooling
DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
-----------------------------------------------------------------------------------------
Key: DERBY-3431
URL: https://issues.apache.org/jira/browse/DERBY-3431
Project: Derby
Issue Type: Bug
Components: JDBC, Network Client
Affects Versions: 10.4.0.0
Environment: Client-server with connection pooling enabled.
Reporter: Kristian Waagan
Priority: Minor
The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3431) DatabaseMetaData.getConnection returns
the wrong connection when using connection pooling
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-3431:
-----------------------------------
Derby Info: [Patch Available]
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.1.3, 10.5.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.5.0.0
>
> Attachments: derby-3431-1a-test_repro.diff, derby-3431-1b-test_repro.diff, derby-3431-2a-test.diff, derby-3431-3a-client_logical_metadata.diff, derby-3431-3a-client_logical_metadata.stat, derby-3431-3b-client_logical_metadata.diff
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3431) DatabaseMetaData.getConnection returns
the wrong connection when using connection pooling
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan closed DERBY-3431.
----------------------------------
No problems reported. Closing.
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.1.3, 10.5.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.5.0.0
>
> Attachments: derby-3431-1a-test_repro.diff, derby-3431-1b-test_repro.diff, derby-3431-2a-test.diff, derby-3431-3a-client_logical_metadata.diff, derby-3431-3a-client_logical_metadata.stat, derby-3431-3b-client_logical_metadata.diff, derby-3431-4a-spt_test_nit.diff
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3431) DatabaseMetaData.getConnection
returns the wrong connection when using connection pooling
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600105#action_12600105 ]
Knut Anders Hatlen commented on DERBY-3431:
-------------------------------------------
> Besides general comments / review, a few points to look at:
> * LogicalDatabaseMetaData.detach : Is this required / worth the
> hassle?
I don't think it's required. The LDMD might hang on to some more
resources if it's not detached, but given that the physical objects
generally live longer than the logical ones, I wouldn't expect that to
cause too much trouble.
LDMD only references two objects: The logical connection and the
physical meta-data object. Since the detach happens when the logical
connection is closed and has released all its resources, preserving
the reference to LC shouldn't do any harm.
Nulling out the physical meta-data object makes more sense, as it has
a reference to the physical connection. What about removing the
detach() method and moving the realMeta field to LogicalConnection
(with a package-private accessor method)? Then realMeta can be nulled
out directly by LogicalConnection.close(), and LDMD doesn't have to
check that logicalCon and realMeta are non-null and open since that'll
be hidden in LogicalConnection.getRealMetaData().
> * What about unwrap / isWrapper for?
The implementation in the patch allows you to access the underlying
physical object, doesn't it? I think it's better if unwrap() only
returns the logical object.
> * The logicalCon.isClosed() check in getRealMetaDataObject - can it
> ever happen?
I don't know. Perhaps if the physical connection dies because of a
severe error? It's probably OK to check that it's open.
Other comments:
LogicalConnection40 has its own private field called
logicalDatabaseMetaData, so the field with the same name in
LogicalConnection isn't used in the JDBC 4.0 driver. I think this
means that detach() is never called in the JDBC 4.0 driver.
I'd say that instead of reimplementing the entire getMetaData() method
in LogicalConnection40, we should have a method called something like
newLogicalMetaData() in LC and LC40. This method should simply create
a new logical meta-data object of the correct subclass and be used by
LC.getMetaData(). Then there's no need to reimplement the caching of
the meta-data objects in LC40.
Nit: assertNotSame() could be removed in the code below since
getConnection() is expected to fail.
+ try {
+ assertNotSame(con2, dmd1.getConnection());
+ fail("Should have thrown no current connection exception");
+ } catch (SQLException sqle) {
+ assertSQLState("08003", sqle);
+ }
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.1.3, 10.5.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.5.0.0
>
> Attachments: derby-3431-1a-test_repro.diff, derby-3431-1b-test_repro.diff, derby-3431-2a-test.diff, derby-3431-3a-client_logical_metadata.diff, derby-3431-3a-client_logical_metadata.stat
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DERBY-3431)
DatabaseMetaData.getConnection returns the wrong connection when using
connection pooling
Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570340#action_12570340 ]
myrna edited comment on DERBY-3431 at 2/19/08 9:55 AM:
--------------------------------------------------------------------
I think this is a duplicate of DERBY-2531, which is a duplicate of DERBY-1018?
was (Author: myrna):
I think this is a duplicate of DERBY-2531?
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.4.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Priority: Minor
> Attachments: derby-3431-1a-test_repro.diff
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3431) DatabaseMetaData.getConnection returns
the wrong connection when using connection pooling
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-3431:
-----------------------------------
Attachment: derby-3431-2a-test.diff
Patch 2a adds a new test to J2EEDataSourceTest. It fails, so it is has been disabled for now.
It is a bit different than DatabaseMetaDataTest.testConnectionSpecific, so both patch 1a and 2a could be committed.
Ready for review.
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Priority: Minor
> Attachments: derby-3431-1a-test_repro.diff, derby-3431-2a-test.diff
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3431) DatabaseMetaData.getConnection returns
the wrong connection when using connection pooling
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-3431:
-----------------------------------
Derby Info: (was: [Patch Available])
Thank you for the continued review Knut Anders.
I committed patch 3b to trunk with revision 662383.
The test nit you pointed out will be addressed shortly in a separate patch.
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.1.3, 10.5.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.5.0.0
>
> Attachments: derby-3431-1a-test_repro.diff, derby-3431-1b-test_repro.diff, derby-3431-2a-test.diff, derby-3431-3a-client_logical_metadata.diff, derby-3431-3a-client_logical_metadata.stat, derby-3431-3b-client_logical_metadata.diff
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3431) DatabaseMetaData.getConnection
returns the wrong connection when using connection pooling
Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570340#action_12570340 ]
Myrna van Lunteren commented on DERBY-3431:
-------------------------------------------
I think this is a duplicate of DERBY-2531?
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.4.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Priority: Minor
> Attachments: derby-3431-1a-test_repro.diff
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3431) DatabaseMetaData.getConnection
returns the wrong connection when using connection pooling
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590414#action_12590414 ]
Kristian Waagan commented on DERBY-3431:
----------------------------------------
The following test code, which I will commit when I get around to it, gives the failures below.
/**
* Tests that DatabaseMetaData.getConnection does not leak references to
* physical connections or other logical connections.
*
* @throws SQLException if something goes wrong
*/
public void testConnectionLeakInDatabaseMetaData()
throws SQLException {
ConnectionPoolDataSource cpDs =
J2EEDataSource.getConnectionPoolDataSource();
PooledConnection pc = cpDs.getPooledConnection();
Connection con1 = pc.getConnection();
DatabaseMetaData dmd1 = con1.getMetaData();
assertSame(con1, dmd1.getConnection());
con1.close();
Connection con2 = pc.getConnection();
DatabaseMetaData dmd2 = con2.getMetaData();
assertSame(con2, dmd2.getConnection());
assertNotSame(con2, dmd1.getConnection());
}
There were 2 failures:
1) testConnectionLeakInDatabaseMetaData(org.apache.derbyTesting.functionTests.tests.jdbcapi.J2EEDataSourceTest)junit.framework.AssertionFailedError: expected not same
at org.apache.derbyTesting.functionTests.tests.jdbcapi.J2EEDataSourceTest.testConnectionLeakInDatabaseMetaData(J2EEDataSourceTest.java:2701)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:103)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
2) testConnectionLeakInDatabaseMetaData(org.apache.derbyTesting.functionTests.tests.jdbcapi.J2EEDataSourceTest)junit.framework.AssertionFailedError: expected same:<or...@1c8ad52> was not:<or...@1eb139e>
at org.apache.derbyTesting.functionTests.tests.jdbcapi.J2EEDataSourceTest.testConnectionLeakInDatabaseMetaData(J2EEDataSourceTest.java:2696)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:103)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
FAILURES!!!
Tests run: 39, Failures: 2, Errors: 0
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Priority: Minor
> Attachments: derby-3431-1a-test_repro.diff
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3431) DatabaseMetaData.getConnection
returns the wrong connection when using connection pooling
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan resolved DERBY-3431.
------------------------------------
Resolution: Fixed
Marking as resolved, awaiting test runs (and other feedback) for confirmation of the fix.
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.1.3, 10.5.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.5.0.0
>
> Attachments: derby-3431-1a-test_repro.diff, derby-3431-1b-test_repro.diff, derby-3431-2a-test.diff, derby-3431-3a-client_logical_metadata.diff, derby-3431-3a-client_logical_metadata.stat, derby-3431-3b-client_logical_metadata.diff, derby-3431-4a-spt_test_nit.diff
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3431) DatabaseMetaData.getConnection returns
the wrong connection when using connection pooling
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-3431:
-----------------------------------
Derby Info: (was: [Patch Available])
Thank you for the comments Knut Anders.
I'll have a look at them and try to finalize the patch today.
Regarding the test nit, I'll remove it. Note that embedded currently returns the same reference there, causing the assertNotSame to fail. It doesn't matter though, as the method is supposed to throw the "No current connection" exception.
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.1.3, 10.5.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.5.0.0
>
> Attachments: derby-3431-1a-test_repro.diff, derby-3431-1b-test_repro.diff, derby-3431-2a-test.diff, derby-3431-3a-client_logical_metadata.diff, derby-3431-3a-client_logical_metadata.stat
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3431) DatabaseMetaData.getConnection returns
the wrong connection when using connection pooling
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-3431:
-----------------------------------
Attachment: derby-3431-3a-client_logical_metadata.stat
derby-3431-3a-client_logical_metadata.diff
'derby-3431-3a-client_logical_metadata.diff' introduces a logical database metadata object in the client driver.
One such object will be created (on demand) for each logical connection. In general it only forwards method calls to the metadata object of the underlying physical connection. If the logical connection is closed, it will not forward the calls even if the underlying physical connection is still open.
Besides general comments / review, a few points to look at:
* LogicalDatabaseMetaData.detach : Is this required / worth the hassle?
* What about unwrap / isWrapper for?
* The logicalCon.isClosed() check in getRealMetaDataObject - can it ever happen?
Regression tests run without failures (except for the SetTransactionIsolation:embedded error).
Patch ready for review.
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.1.3, 10.5.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.5.0.0
>
> Attachments: derby-3431-1a-test_repro.diff, derby-3431-1b-test_repro.diff, derby-3431-2a-test.diff, derby-3431-3a-client_logical_metadata.diff, derby-3431-3a-client_logical_metadata.stat
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3431) DatabaseMetaData.getConnection
returns the wrong connection when using connection pooling
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591597#action_12591597 ]
Kristian Waagan commented on DERBY-3431:
----------------------------------------
Committed 'derby-3431-2a-test.diff' to trunk with revision 650814.
The test is still disabled.
Leaving patch available flag set, I'll look into getting the other test committed as well. And of course, a fix has to be made as well :)
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.0.0, 10.5.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Priority: Minor
> Attachments: derby-3431-1a-test_repro.diff, derby-3431-2a-test.diff
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3431) DatabaseMetaData.getConnection
returns the wrong connection when using connection pooling
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12589081#action_12589081 ]
Kristian Waagan commented on DERBY-3431:
----------------------------------------
Was the previous comment meant for DERBY-1018?
Anyway, I think we might have to introduce a logical meta data object, because only a single instance is being used per connection. If we don't add a wrapper class, references to the physical connection itself or other logical connections will leak out to the user.
A wrapper object is not used in the embedded driver, but as far as I can see there is a bug in the implementation. The bug causes connection references to "leak", in such a way that user A with logical connection 1, at a later time (after connection 1 is closed) can obtain a reference to logical connection 2 created by user B. I will log this bug tomorrow with a repro.
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Priority: Minor
> Attachments: derby-3431-1a-test_repro.diff
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3431) DatabaseMetaData.getConnection
returns the wrong connection when using connection pooling
Posted by "Dyre Tjeldvoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587203#action_12587203 ]
Dyre Tjeldvoll commented on DERBY-3431:
---------------------------------------
I've been thinking a bit about how best to address this issue. As far as I can see there are 3 different ways of solving this:
1) Let LogicalConnection.createStatement() (and perhaps prepareStatement and similar methods) overwrite the connection_ variable inside Statement with a reference to itself (a LogicalConnection). This has the disadvantage of changing an internal member variable that is used for, among other things, synchronization.
2) Create a new member variable (logicalConnection_) which normally is null, but is set to point to the LogicalConnection which created the statement (if a LogicalConnection was used)
3) Force all use of Statements to use a LogicalStatement whenever connection pooling is used (even when statement pooling is not enabled). This would make the code more uniform, but adds an unnecessary level of indirection when statement caching is not used.
Thoughts?
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Priority: Minor
> Attachments: derby-3431-1a-test_repro.diff
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3431) DatabaseMetaData.getConnection
returns the wrong connection when using connection pooling
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600052#action_12600052 ]
Kristian Waagan commented on DERBY-3431:
----------------------------------------
I plan to commit this patch tomorrow.
Would be nice if someone could look at it to get rid of any initial problems with the patch.
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.1.3, 10.5.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.5.0.0
>
> Attachments: derby-3431-1a-test_repro.diff, derby-3431-1b-test_repro.diff, derby-3431-2a-test.diff, derby-3431-3a-client_logical_metadata.diff, derby-3431-3a-client_logical_metadata.stat
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3431) DatabaseMetaData.getConnection returns
the wrong connection when using connection pooling
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-3431:
-----------------------------------
Attachment: derby-3431-4a-spt_test_nit.diff
'derby-3431-4a-spt_test_nit.diff' addresses the test nit.
Committed to trunk with revision 662386.
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.1.3, 10.5.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.5.0.0
>
> Attachments: derby-3431-1a-test_repro.diff, derby-3431-1b-test_repro.diff, derby-3431-2a-test.diff, derby-3431-3a-client_logical_metadata.diff, derby-3431-3a-client_logical_metadata.stat, derby-3431-3b-client_logical_metadata.diff, derby-3431-4a-spt_test_nit.diff
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3431) DatabaseMetaData.getConnection returns
the wrong connection when using connection pooling
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-3431:
-----------------------------------
Derby Info: (was: [Patch Available])
Fix Version/s: 10.5.0.0
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.1.3, 10.5.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.5.0.0
>
> Attachments: derby-3431-1a-test_repro.diff, derby-3431-1b-test_repro.diff, derby-3431-2a-test.diff
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3431) DatabaseMetaData.getConnection
returns the wrong connection when using connection pooling
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601574#action_12601574 ]
Knut Anders Hatlen commented on DERBY-3431:
-------------------------------------------
Thanks for the new patch, Kristian! The changes look good to me. +1 to commit.
A tiny nit in StatementPoolingTest; the code below could be expressed with an assertEquals now that there's only one condition:
if (!simpleName.equals(expectedName)) {
- if (!simpleName.equals(expectedName + "40")) {
- fail("Expected class name " + expectedName + " or " +
- expectedName + "40, got " + simpleName);
- }
+ fail("Expected class name " + expectedName + ", got " +
+ simpleName);
}
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.1.3, 10.5.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.5.0.0
>
> Attachments: derby-3431-1a-test_repro.diff, derby-3431-1b-test_repro.diff, derby-3431-2a-test.diff, derby-3431-3a-client_logical_metadata.diff, derby-3431-3a-client_logical_metadata.stat, derby-3431-3b-client_logical_metadata.diff
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3431) DatabaseMetaData.getConnection returns
the wrong connection when using connection pooling
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-3431:
-----------------------------------
Derby Info: [Patch Available]
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Priority: Minor
> Attachments: derby-3431-1a-test_repro.diff, derby-3431-2a-test.diff
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3431) DatabaseMetaData.getConnection returns
the wrong connection when using connection pooling
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-3431:
-----------------------------------
Affects Version/s: 10.1.3.1
10.2.2.0
10.3.2.1
Updating affected versions based on what's reported in DERBY-1018.
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Priority: Minor
> Attachments: derby-3431-1a-test_repro.diff
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3431) DatabaseMetaData.getConnection returns
the wrong connection when using connection pooling
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-3431:
-----------------------------------
Affects Version/s: 10.5.0.0
Assignee: Kristian Waagan
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.0.0, 10.5.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Attachments: derby-3431-1a-test_repro.diff, derby-3431-2a-test.diff
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3431) DatabaseMetaData.getConnection
returns the wrong connection when using connection pooling
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600492#action_12600492 ]
Kristian Waagan commented on DERBY-3431:
----------------------------------------
With the exception of "SetTransactionIsolation:embedded", suites.All and derbyall ran without failures with patch 3b.
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.1.3, 10.5.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.5.0.0
>
> Attachments: derby-3431-1a-test_repro.diff, derby-3431-1b-test_repro.diff, derby-3431-2a-test.diff, derby-3431-3a-client_logical_metadata.diff, derby-3431-3a-client_logical_metadata.stat, derby-3431-3b-client_logical_metadata.diff
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3431) DatabaseMetaData.getConnection returns
the wrong connection when using connection pooling
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-3431:
-----------------------------------
Attachment: derby-3431-3b-client_logical_metadata.diff
'derby-3431-3b-client_logical_metadata.diff' addresses the comments Knut Anders made, and contains a few other minor changes.
-- StatementPoolingTests
Extended test to check for implementation class, to make sure a JDBC 4 class is returned in a JDBC 4 env.
-- Reference to the real metadata object
There is no reference to the real / physical metadata object anymore. The getMetaData method of the physical connection is called each time the object needs to be accessed.
-- LogicalDatabaseMetaData.getRealMetaDataObject
I was a bit lazy and didn't want to remove the method, as it would probably require that many lines would become longer than 80 characters... Can be removed (make logicalCon protected / package-private then).
The regression tests passed, but I made a few late changes so I'm running them again. Will report back when they're done.
Patch ready for another round of review.
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.1.3, 10.5.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.5.0.0
>
> Attachments: derby-3431-1a-test_repro.diff, derby-3431-1b-test_repro.diff, derby-3431-2a-test.diff, derby-3431-3a-client_logical_metadata.diff, derby-3431-3a-client_logical_metadata.stat, derby-3431-3b-client_logical_metadata.diff
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3431) DatabaseMetaData.getConnection returns
the wrong connection when using connection pooling
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-3431:
-----------------------------------
Derby Info: [Patch Available]
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.1.3, 10.5.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.5.0.0
>
> Attachments: derby-3431-1a-test_repro.diff, derby-3431-1b-test_repro.diff, derby-3431-2a-test.diff, derby-3431-3a-client_logical_metadata.diff, derby-3431-3a-client_logical_metadata.stat
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3431) DatabaseMetaData.getConnection returns
the wrong connection when using connection pooling
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-3431:
-----------------------------------
Attachment: derby-3431-1a-test_repro.diff
I have not tested this with earlier releases yet, but I suspect the bug is present there as well.
I'm attaching a repro in the form of a diff for DatabaseMetaDataTest.
When run on trunk, I get these two failures (XADS and CPDS):
junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest
.........................................
..............................F.F.
Time: 180.262
There were 2 failures:
1) testConnectionSpecific(org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest)junit.framework.AssertionFailedError: expected same:<or...@696ad1> was not:<or...@e3e688>
at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.testConnectionSpecific(DatabaseMetaDataTest.java:708)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:99)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
2) testConnectionSpecific(org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest)junit.framework.AssertionFailedError: expected same:<or...@636b5> was not:<or...@1f1c3dc>
at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.testConnectionSpecific(DatabaseMetaDataTest.java:708)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:99)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
FAILURES!!!
Tests run: 73, Failures: 2, Errors: 0
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.4.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Priority: Minor
> Attachments: derby-3431-1a-test_repro.diff
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3431) DatabaseMetaData.getConnection returns
the wrong connection when using connection pooling
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-3431:
-----------------------------------
Attachment: derby-3431-1b-test_repro.diff
'derby-3431-1b-test_repro.diff' is almost identical to 1a except for some minor tweaks.
Only the test for embedded has been enabled, as the test fails with the client driver.
Committed 'derby-3431-1b-test_repro.diff' to trunk with revision 658181.
> DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3431
> URL: https://issues.apache.org/jira/browse/DERBY-3431
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.1.3, 10.5.0.0
> Environment: Client-server with connection pooling enabled.
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.5.0.0
>
> Attachments: derby-3431-1a-test_repro.diff, derby-3431-1b-test_repro.diff, derby-3431-2a-test.diff
>
>
> The connection returned from DatabaseMetaData.getConnection is not the same as the connection used to create the meta data object when the client driver is used with connection pooling enabled.
> For trunk, the embedded driver/ds does the right thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.