db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Samuel Andrew McIntyre (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-293) Correlate client connection with embedded connection
Date Sat, 04 Jun 2005 04:28:47 GMT
     [ http://issues.apache.org/jira/browse/DERBY-293?page=all ]

Samuel Andrew McIntyre updated DERBY-293:
-----------------------------------------

    Fix Version: 10.2.0.0
                     (was: 10.1.0.0)
    Description: 
There should be a way for someone to correlate a given embedded connection with its matching
network client connection, if such a client connection exists.  

See 

http://article.gmane.org/gmane.comp.apache.db.derby.devel/3748

and

http://article.gmane.org/gmane.comp.apache.db.derby.devel/3942

for some background info on how to get useful information out of the DRDA protocol
stream to accomplish this.

This could be done either by modifying the toString() method of an embedded
connection to show its associated network client connection information or (my
preference) include this information in the proposed Connection VTI (see DERBY-292).  I am
worried that if we use toString() for this, the output will be overly long and complicated;
also, over a period of time the same embedded connection may be associated with multiple client
connections, resulting in a changing toString() value for the embedded connection.  This seems
problematic if we are intending toString() to uniquely identify a connection for the lifetime
of the connection -- this would be a good goal to have as it would enable us to do some useful
debugging using the VTIs.

  was:
There should be a way for someone to correlate a given embedded connection with its matching
network client connection, if such a client connection exists.  

See 

http://article.gmane.org/gmane.comp.apache.db.derby.devel/3748

and

http://article.gmane.org/gmane.comp.apache.db.derby.devel/3942

for some background info on how to get useful information out of the DRDA protocol
stream to accomplish this.

This could be done either by modifying the toString() method of an embedded
connection to show its associated network client connection information or (my
preference) include this information in the proposed Connection VTI (see DERBY-292).  I am
worried that if we use toString() for this, the output will be overly long and complicated;
also, over a period of time the same embedded connection may be associated with multiple client
connections, resulting in a changing toString() value for the embedded connection.  This seems
problematic if we are intending toString() to uniquely identify a connection for the lifetime
of the connection -- this would be a good goal to have as it would enable us to do some useful
debugging using the VTIs.


> Correlate client connection with embedded connection
> ----------------------------------------------------
>
>          Key: DERBY-293
>          URL: http://issues.apache.org/jira/browse/DERBY-293
>      Project: Derby
>         Type: Improvement
>     Versions: 10.1.0.0
>  Environment: N/A
>     Reporter: David Van Couvering
>     Priority: Minor
>      Fix For: 10.2.0.0

>
> There should be a way for someone to correlate a given embedded connection with its matching
network client connection, if such a client connection exists.  
> See 
> http://article.gmane.org/gmane.comp.apache.db.derby.devel/3748
> and
> http://article.gmane.org/gmane.comp.apache.db.derby.devel/3942
> for some background info on how to get useful information out of the DRDA protocol
> stream to accomplish this.
> This could be done either by modifying the toString() method of an embedded
> connection to show its associated network client connection information or (my
> preference) include this information in the proposed Connection VTI (see DERBY-292).
 I am worried that if we use toString() for this, the output will be overly long and complicated;
also, over a period of time the same embedded connection may be associated with multiple client
connections, resulting in a changing toString() value for the embedded connection.  This seems
problematic if we are intending toString() to uniquely identify a connection for the lifetime
of the connection -- this would be a good goal to have as it would enable us to do some useful
debugging using the VTIs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message