One thought I had about the UUID approach, after proposing it, is that
if you're trying to correlate connections and trace messages and you
have these huge long UUID strings, it can be a bit challenging.
If it were a simple static long that starts at 1 and increments each
time a new connection instance is created (yes, the increment would have
to be synchronized), then it would be much more readable. This would
also be more portable to the client code, and we wouldn't have to
cut/paste the UUID class to the client packages...
Any thoughts?
Thanks,
David
David Van Couvering wrote:
Hi, Kathey. Currently the connection classes don't appear to have a
unique identifier that could be made available in toString(). Do I take
it you would like me to find an approach that generates one?
I noticed Derby has a UUID service (very nice!). Is it OK if I use that
here to generate a UUID for the connection? If I don't hear otherwise,
I'll assume this approach is OK, e.g.
public class EmbedConnection
{
private UUID UUIDValue;
private String UUIDString;
public EmbedConnection()
{
UUIDFactory uuidFactory = Monitor.getMonitor().getUUIDFactory();
UUIDValue = uuidFactory.createUUID();
UUIDString = this.getClass().getName() + ":" + UUIDValue.toString();
...
}
public String toString()
{
UUIDString;
}
}
=====
The connection classes I found are as follows. Please let me know if I
missed any. An indented class implies it extends the unindented class
above it.
EMBEDDED (org.apache.derby.engine.*)
BrokeredConnection (implements java.sql.Connection)
BrokeredConnection30
EmbedConnection (implements java.sql.Connection)
EmbedConnection30
EmbedPooledConnection (implements java.sql.PooledConnection)
EmbedXAConnection
CLIENT (org.apache.derby.client.*_
Connection (abstract class, implements java.sql.Connection))
NetConnection
NetXAConnection
ClientXAConnection (implements java.sql.XAConnection)
ClientPooledConnection (implements java.sql.PooledConnection)
LogicalConnection (implements java.sql.Connection)
On the client side, I first need to understand: is derbyclient.jar
supposed to be standalone (meaning it can't depend upon things in
derby.jar like the Monitor and the UUID class). If so, I suppose I
could cut/paste the BasicUUID class into the client packages for use on
the client side (shiver). Alternately we could have a derbyutils.jar
that is shared between client and server (Big Change, not sure if I want
to take that on). Advice here would be most appreciated.
Thanks,
David
Kathey Marsden (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-243?page=all ]
Kathey Marsden updated DERBY-243:
---------------------------------
Summary: connection toString should uniquely identify the
connection (was: connection toString doesn't give enough information)
Description: 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.
was:
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
I am not sure if XA Connections and Pooled Connections have the same
issue. I didn't immediately see an override of the toString() method
in BrokeredConnection.java like there is for EmbedConnection
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: 10.0.2.1, 10.0.2.0, 10.0.2.2, 10.1.0.0
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.
|
