db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-243) connection toString should uniquely identify the connection
Date Thu, 12 May 2005 13:11:43 GMT
Ah, great feedback, thanks.  If there actually is a desire for 
toString() for these guys, I can easily add them, as independent from 
the application-visible connection objects.

David

Dibyendu Majumdar wrote:

> David,
> 
> Agreed, but I am developing a JTA compliant transaction manager.
> So, my interest is also in PooledConnection and XAConnection.
> 
> Regards
> ----- Original Message ----- 
> From: "David Van Couvering" <David.Vancouvering@Sun.COM>
> To: "Derby Development" <derby-dev@db.apache.org>
> Sent: Thursday, May 12, 2005 12:14 AM
> Subject: Re: [jira] Updated: (DERBY-243) connection toString should uniquely
> identify the connection
> 
> 
> 
>>Hi, Dibyendu.  You are quoting an email that's a few exchanges old.  My
>>latest proposal is actually for PooledConnection and XAConnection to not
>>have a toString() at all.  As I'm learning myself, when the application
>>does "conn.toString()" it's never on PooledConnection or XAConnection.
>>Application code never sees these classes.  They are used by connection
>>pool providers such as app server containers.  These aren't "really"
>>connections, they are something that deliver connections from a pool.
>>
>>The one "wrapper" connection that is seen by applications is
>>BrokeredConnection.  In this case I suppose we could print the id of
>>BrokeredConnection as well as the underlying physical connection, but
>>I'm not sure what value this provides.  The user would wonder why
>>they're seeing two distinct connection ids for a given connection.
>>Since BrokerConnection is a wrapper, I am proposing that it should just
>>print out the toString() of the underlying "real" connection.
>>
>>David
>>
>>Dibyendu Majumdar wrote:
>>
>>
>>>From: "David Van Couvering" <David.Vancouvering@Sun.COM>
>>>
>>>>Regarding pooled connections, unless I hear otherwise, I'll modify this
>>>>to not get the id from the underlying physical connection but to have
>>>>its own id instead, so that these are traceable independently.
>>>
>>>
>>>Hi,
>>>
>>>Is it possible to have both - ie - the id for the PooledConnection and
> 
> the
> 
>>>underlying Connection to be dumped? Similarly for XAConnection?
>>>
>>>Regards
>>>
>>>
>>>
>>>
> 
> 
> 

Mime
View raw message