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
