db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: [jira] Updated: (DERBY-243) connection toString should uniquely identify the connection
Date Tue, 10 May 2005 03:30:26 GMT
David Van Couvering wrote:

> Thanks for the quick reply, Dan, some responses below.
> Daniel John Debrunner wrote:

>> I'd like to see some crisper definition around what the return from
>> toString() is meant to represent for a connection.
>> - with this implementation, two different application connections from
>> the same PooledConnection end up with the same toString() output,
>> because the toString() of the underlying connection is used.
> I am still learning about PooledConnection, not having dealt with this
> before.  I thought that PooledConnection was an interface only used by
> app servers and other containers implementing connection pools.  This
> seems to match what I saw in my tests: regardless of what kind of access
> mechanism I used (DriverManager, DataSource, ConnectionPoolDataSource or
> XADataSource), I always ended up with an EmbedConnection30 or a
> NetConnection being returned to the application, and never a
> PooledConnection class.

You are right, I was talking about the connection's returned to the
application, with your code in this case connection a and b have the
same id, where pc is a PooledConnection object.

Connection a = pc.getConnection();
// some work
Connection b = pc.getConnection();

Now I know a is closed once b is obtained, but if there share the same
id then diagnostics might be confusing, as it will be impossible to tell
the activity against connection a to that against connection b. Maybe
that's ok, I'm not sure at the moment what you want the return from
toString() to represent.

> [snap]
> I guess this could be solved if I follow Jack's original suggestion and
> used hashCode(), since this will be unique across all objects in a VM.
> But personally a simple integer id is a lot easier to read in a log file
> than a longer hex number, or an even longer decimal number...  The
> connection id *could* be prepended with a system id, if such a thing
> exists.

I thought we had decided that the hashCode was not guaranteed to be unique.

> However, thinking even further ahead, if we ever had a clustered system
> writing to a common log, even the Jack's identityHashCode solution would
> not be unique :)  Which takes us back to a UUID.  What do you think,
> should we worry about this or just worry about two systems in the same
> VM for now?
> Another thing that would be very nice is if, in client/server mode,
> client connection toString() has a correlation to the resulting embedded
> connection toString() created on the server side for that session.  This
> way you could get end-to-end correlation.  I don't know if DRDA supports
> this; if people think this is a good idea I can investigate...

I think that is there, there is a drda id which I think fulfills that

> Sigh, and I thought this would be a simple fix, silly me! :)

Sad thing is, with an eight year old project, all the easy fixes have
been done already. :-(

>> I would like to see that at some point the return from toString() could
>> be used to correlate the connection with information from a diagnostic
>> table (vti). For example the value of PreparedStatement.toString()
>> corresponds to the identifier column of the statement cache vti.
>> This then could be used in diagnostics to show something like all locks
>> for this connection.
> Sorry, what's "vti"?  This is a Derby acronym I have seen while browsing
> the source, I *think* it means "virtual table" but I'm not sure...  Does
> such a diagnostic table exist?  Where would I look to find one?

Virtual Table Interfacce, see the classes in org.apache.derby.diag

> I looked at EmbedPreparedStatement.  Its toString() invokes
> super.toString().  It's superclass is EmbedStatement, which has no
> toString() defined, and its superclass is ConnectionChild, which has no
> toString() defined.  So you end up with <classname>@<hashCode>.

No, you missed some code in EmbedPreparedStatement.toString(), if it
has an activation, then it returns a value from its language prepared
> However, further digging reveals diag.StatementCache.java refers to
> GenericPreparedStatement.getObjectName(), which is a UUIDString.
> At this point I must confess I am a bit lost.  I can't find the
> relationship, BTW, between GenericPreparedStatement and
> EmbedPreparedStatement, and I can't figure out how diag.StatementCache
> is related to a VTI.  Any guidance would be most appreciated.

StatementCache is a VTI, you can execute the statement

select * from new org.apache.diag.StatementCache() AS SC

to get a list of statements in the cache.

And use a where clause to match the current statement to its cache entry
 by using the output from toString() of the PreparedStatement.

View raw message