Daniel John Debrunner wrote:
David Van Couvering wrote:
I haven't heard any responses on this, so I am going to make the following changes/actions. Speak now or... speak later, I guess :)
- Use UUID to generate a unique id. On the engine side I will use the UUID service; on the client side I will use BasicUUID hardcoded.
Sounds fine, but what still is the uniqueness of the string in just the *simple* cases, never mind the multiple class loaders, multiple jvms etc?
Apologies if I wasn't clear about this. In my previous email, I argued that even in a "simple" case such as the network client, you can regularly be running in multiple classloaders (e.g. when Derby is running in an app server container). So, rather than make this a configurable option where users have to figure out when they need use UUIDs, I was just going to use UUID all the time.
- 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.
- subsequent application connections returned from PooledConnection.getConnection() - Unique I hope.
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.
In summary, each physical connection should have its own unique connection id, regardless of how it is obtained by the application.
The alternative is to "regenerate" a new id each time a connection is pulled off of the pool, but this seemed to create a concept of a "virtual" connection that only lasts the lifetime of a transaction. This just doesn't seem right...
David
Dan.
