Kathey Marsden wrote:
David Van Couvering (JIRA) wrote:
I have replaced the old patch with this one. This one uses UUID to identify a connection string.
It also provides independent connection strings for PooledConnection classes.
Hi David
Just so I understand the connection id semantics as I review this patch, could you tell me whether the following statements are true or false with regard to your patch. Please specify if the behaviour is different for embedded and client.
1) Each physical connection has its own unique connection id, regardless of how it is obtained by the application.
Yes, that's right
2) If a stored procedure is called from a connection with connection id X, and the stored procedure obtains a connection with DriverManager.getConnection("jdbc:default:connection"), the connection in the stored procedure will also have connection id X.
Yes, that's right
3) Every logical connection obtained from a single pooled connection will have the same connection id.
This should generally be the case, because BrokeredConnection.toString() and LogicalConnection.toString() delegate to their underlying physical connections, which are owned by one and only one pooled connection (as far as I can see).
However, if for some reason a pooled connection needs to associate itself with a new physical connection, there is nothing in the code I added that prevents this, and then you will get a new id when you call getConnection(). I couldn't see any code that exists that actually does this, but I didn't make any specific assumptions of a 1-1 correspondence between pooled connection and the underlying physical connection.
Thanks,
David
Thanks
Kathey
