This is our transactionManager node

    <transactionManager type="JDBC" commitRequired="true">
        <dataSource type="JNDI">
            <property name="DataSource" value="jdbc/medical"/>
        </dataSource>
    </transactionManager>

On Fri, Aug 8, 2008 at 11:32 AM, Michael Schall <[EMAIL PROTECTED]>wrote:

> We are using jndi.
>
>
> On Fri, Aug 8, 2008 at 11:30 AM, Clinton Begin <[EMAIL PROTECTED]>wrote:
>
>> If you're using SImpleDataSource, then yes.  You can cast the
>> datasource into a simpledatasource and you'll find a method called
>> getStatus()
>>
>> public String getStatus() {
>>    StringBuffer buffer = new StringBuffer();
>>
>>
>>  
>> buffer.append("\n===============================================================");
>>    buffer.append("\n jdbcDriver                     ").append(jdbcDriver);
>>    buffer.append("\n jdbcUrl                        ").append(jdbcUrl);
>>    buffer.append("\n jdbcUsername
>> ").append(jdbcUsername);
>>    buffer.append("\n jdbcPassword
>> ").append((jdbcPassword == null ? "NULL" : "************"));
>>    buffer.append("\n poolMaxActiveConnections
>> ").append(poolMaximumActiveConnections);
>>    buffer.append("\n poolMaxIdleConnections
>> ").append(poolMaximumIdleConnections);
>>    buffer.append("\n poolMaxCheckoutTime            " +
>> poolMaximumCheckoutTime);
>>    buffer.append("\n poolTimeToWait                 " + poolTimeToWait);
>>    buffer.append("\n poolPingEnabled                " + poolPingEnabled);
>>    buffer.append("\n poolPingQuery                  " + poolPingQuery);
>>    buffer.append("\n poolPingConnectionsOlderThan   " +
>> poolPingConnectionsOlderThan);
>>    buffer.append("\n poolPingConnectionsNotUsedFor  " +
>> poolPingConnectionsNotUsedFor);
>>    buffer.append("\n
>> --------------------------------------------------------------");
>>    buffer.append("\n activeConnections              " +
>> activeConnections.size());
>>    buffer.append("\n idleConnections                " +
>> idleConnections.size());
>>    buffer.append("\n requestCount                   " +
>> getRequestCount());
>>    buffer.append("\n averageRequestTime             " +
>> getAverageRequestTime());
>>    buffer.append("\n averageCheckoutTime            " +
>> getAverageCheckoutTime());
>>    buffer.append("\n claimedOverdue                 " +
>> getClaimedOverdueConnectionCount());
>>    buffer.append("\n averageOverdueCheckoutTime     " +
>> getAverageOverdueCheckoutTime());
>>    buffer.append("\n hadToWait                      " +
>> getHadToWaitCount());
>>    buffer.append("\n averageWaitTime                " +
>> getAverageWaitTime());
>>    buffer.append("\n badConnectionCount             " +
>> getBadConnectionCount());
>>
>>  
>> buffer.append("\n===============================================================");
>>    return buffer.toString();
>>  }
>>
>>
>> Clinton
>>
>> On Fri, Aug 8, 2008 at 10:09 AM, Michael Schall <[EMAIL PROTECTED]>
>> wrote:
>> > Is there a way to know when a connection is retrieved from the pool and
>> > returned to the pool and how long the request for a connection takes?  I
>> > have looked at the ConnectionLogProxy, but I assume this is too late in
>> the
>> > game.  We already have the connection at that point?
>> >
>> > The problem I'm tring to find is our connections seem to be slowly
>> leaking
>> > and I can't pinpoint where the leak might be.  We have hundreds of users
>> hit
>> > the site pretty hard and we have the maxConnections set to 32 within
>> > WebSphere.  If it was a systemic problem, we would use all the
>> connections
>> > by the 33 request right?  I would like to log the activity to see if I
>> can
>> > find the problem.
>> >
>> > Is there a way to uniquely identifiy a connection?  So when testing I
>> can
>> > see that I'm reusing the same connection vs. a new one?  Using log4j I
>> get
>> > "{conn-100036} Connection" in the log, but the "100036" is just an
>> > incrementing number.  Is there a property on the connection that would
>> tell
>> > us this query is using the same connection as that query?
>> >
>> > Thanks for your help.
>> >
>> > Mike
>> >
>>
>
>

Reply via email to