db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3431) DatabaseMetaData.getConnection returns the wrong connection when using connection pooling
Date Tue, 27 May 2008 12:25:41 GMT

    [ 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:,,,,
>         Environment: Client-server with connection pooling enabled.
>            Reporter: Kristian Waagan
>            Assignee: Kristian Waagan
>            Priority: Minor
>             Fix For:
>         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
> 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.

View raw message