I'll take silence as consent? I'll go ahead with a simple incrementing
counter approach.
David
David Van Couvering wrote:
Although I agree you don't want your debug code to bog down your
production code, when it is time to debug, your debug code is very
important. When I am debugging a nasty contention issue, and I get two
connections with the exact same id, then that could be a REAL problem.
Also, I can imagine providing a getId() method on Connection that could
be used for other things within the system. It would be nice if we
could guarantee uniqueness.
I agree that identityHashCode is probably fine. But I think that a
basic incrementing counter is very simple to implement, and then we
could be assured of uniqueness. I do notice that an incrementing
counter is already implemented in a number of other places in the code
already, so this wouldn't be a new thing.
However, I will be happy to go with identityHashCode if that is the
general consensus.
David
Jack Klebanoff wrote:
If the Derby client absolutely requires that its Connection class
toString methods return unique, that is if the client would fail to
work if toString() were not unique, then we could toString could not
use identityHashCode. However, I do not believe that this is the case.
I think that uniqueness is very helpful but not required.
It is true that identityHashCode is not guaranteed to be unique.
However, in practice it almost always is unique.
My understanding is that toString is used for debugging. I don't think
that we should burden the production with debug code when we have
simpler methods that, in practice if not in theory, will work just fine.
Jack Klebanoff
David Van Couvering wrote:
Hm, I always thought a hash-code was not unique. I got excited when
you mentioned this method, identityHashCode(), which I hadn't heard
of, but it basically delegates to Object.hashCode(), it just ensures
that the hash code returned is the base Object hash code and not one
returned by an overriding method.
The documentattion for hashCode() says
"It is not required that if two objects are unequal according to the
equals(java.lang.Object) method, then calling the hashCode method on
each of the two objects must produce distinct integer results.
However, the programmer should be aware that producing distinct
integer results for unequal objects may improve the performance of
hashtables.
As much as is reasonably practical, the hashCode method defined by
class Object does return distinct integers for distinct objects.
(This is typically implemented by converting the internal address of
the object into an integer, but this implementation technique is not
required by the JavaTM programming language.)"
So, we can depend on it *most* of the time, but that makes me a bit
nervous...
David
Jack Klebanoff wrote:
The simplest thing would be to use the
java.lang.System.identityHashCode method on the connection object. I
believe that it is unique in a 32 bit system. In practice it will
almost always be unique in a 64 bit system.
I don't think that the Monitor or UUIDFactory classes are available
in the client.They are part of the Derby server.
Jack Klebanoff
||David Van Couvering wrote:
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.
