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 purpose. > 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 statement. > > 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.
