db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: [jira] Updated: (DERBY-243) connection toString should uniquely identify the connection
Date Wed, 11 May 2005 20:25:26 GMT
David Van Couvering wrote:
> 
> 
> Daniel John Debrunner wrote:

>>
>> - Connections returned from jdbc:default:connection?
>>   Unique string or string of parent connection?
> 
> 
> I'm not sure what you mean by "parent connection.".  Is this a
> class-hierarchy relationship or some other kind of relationship?  Each
> physical connection should have its own unique connection string.  If it
> is a subclass of another connection class, it will inherit the code to
> obtain a connection id, but the instance will have its own independent
> string.

This is a nested connection, as defined by the SQL spec. Used within
server-side JDBC code to obtain a connection object that is in the
transaction space of the Connection calling the Java procedure or
function. If you look at the jdbcapi/checkDataSource test you can
procedure calls that obtain a connection using the JDBC URL
jdbc:default:connection. Or procedures called from the lang/procedures test.

> Well, I discussed this in my previous email, and argued that a
> NetConnection or EmbedConnection (which is what is returned from
> PooledConnection.getConnection()) should have a single id that lasts the
> lifetime of the instance.  If two separate transacations in separate
> threads get the same underlying EmbedConnection or NetConnection from a
> PooledConnection, then they will have the same id.  This actually seemed
> good -- it's more accurate and does not hide the reality of connection
> pooling.

Technically EmbedConnection objects are not returned from
PooledConnection.getConnection. Instead a EmbedConnection object wrapped
by a BrokeredConnection is returned. The EmbedConnection is the physical
connection and the BrokeredConnection is the logical Connection object.

> In summary, each physical connection should have its own unique
> connection id, regardless of how it is obtained by the application.

That's a good definition. And it means the nested connection would need
to have same toString() value as its parent.

OK


Mime
View raw message