db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-243) connection toString should uniquely identify the connection
Date Wed, 11 May 2005 20:44:17 GMT


Daniel John Debrunner wrote:

> 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.
>

Ah, OK, I understand.  I had forgotten about accessing connections from 
stored procedures.  I should add this to my test changes, make sure that 
a valid, unique string is coming out of a connection obtained from 
jdbc:default:connection.

> 
>>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.
> 

OK, thanks.  I should just draw a picture on my whiteboard, except that 
I'm in a different office each day :)

That said, if I understand things correctly, the BrokeredConnection is 
mostly a proxy to catch things like Connection.close(), and that the 
right thing to do in this case is return the toString() of the 
underlying EmbedConnection.   We should always delegate to the actual 
physical database connection, just like BrokeredConnection does for 
everything else.

I'll assume I got this right; let me know if you disagree.

> 
>>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

OK :)

I'll give this another go.

David
> 

Mime
View raw message