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" <[EMAIL PROTECTED]> To: "Derby Development" <[email protected]> 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" <[EMAIL PROTECTED]> > > > >>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 > > > > > > > >
