db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Van Couvering (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-243) connection toString should uniquely identify the connection
Date Tue, 24 May 2005 16:52:56 GMT
     [ http://issues.apache.org/jira/browse/DERBY-243?page=comments#action_66181 ]
David Van Couvering commented on DERBY-243:

In my investigations to understand how to add the connection string to VTIs, I have thought
further about this item, and it has become clear to me that storing the unique id in the Connection
object is putting it at the wrong level.  If, for example, we ever want to provide a separate
API for obtaining a session into the Derby database outside of JDBC, this information would
not be available.

For this reason, it makes much more sense to use the LanguageConnectionContext as the owner
of a unique identification for the session.  

As some of our discussion has revealed, the LanguageConnectionContext already has an instance
number, printed out as either "SESSIONID" or "LCCID" in the logs and VTIs.  One could argue
that we should just use this id.  However, this id is a simple static integer incremented
each time a new LanguageConnectionContext is created, and my concerns about loss of uniqueness
across classloaders stands for this id, and I think it is going to cause us problems, particularly
in the context of an app server where there is normally a separate classloader for each deployed

I am recommending that we add a new method to LanguageConnectionContext, UUID getId().  Connection.toString()
will return "Connection_" + the String representation of this id.  

Also, today our error logs and VTIs today all use the existing instance number as the LanguageConnectionContext
id (SESSIONID or LCCID).  I would like to propose that this be replaced to print out the new
UUID instead.  

Pooled connections, as we have already discussed, have their own separate identity, and I
am recommending that we keep them using their own UUID as it is already implemented.

> connection toString should uniquely identify the connection
> -----------------------------------------------------------
>          Key: DERBY-243
>          URL: http://issues.apache.org/jira/browse/DERBY-243
>      Project: Derby
>         Type: Improvement
>   Components: JDBC
>     Reporter: Kathey Marsden
>     Assignee: David Van Couvering
>     Priority: Trivial
>      Fix For:,,,
>  Attachments: DERBY-243.diff
> The toString() on the Derby connection doesn't print 
> unique information.
> for example  System.out.println(conn) prints:
> EmbedConnection  in the case of derby embedded
> It would be great if the toString() method for connections could be used to differentiate
one connection from another.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message