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
