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" <[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
