java.sql.SQLException: Error accessing jdbc driver: driverURL =
jdbc:weblogic:pool:srPool, props = {connectionPoolID=srPool,
enableTwoPhaseCommit=false}
at weblogic.jdbc.jts.Driver.wrapAndThrowSQLException(Driver.java:272)
at weblogic.jdbc.jts.Driver.getNonTxConnection(Driver.java:326)
at weblogic.jdbc.jts.Driver.connect(Driver.java:120)
at
weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:214)
So, no exceptions for an hour, then this exception several times a second.
At the same time, the Execute Queue Length started filling up,
ConnectionPoolWaiters jumped, and the server became essentially unusable.
I took 2 thread dumps 10 minutes apart once the server began acting up.
I don't know if it helps, but here are the results (we have 80 threads in the
ExecuteQueue and no other user-defined queues.):
Activity : Threads in dump1 : Threads in dump2
------------------------------------
Converting NUMBER type in db to java object : 53 : 35
Waiting for a database connection : 24 : 3
Waiting in PosixSocketMuxer : 3 : 3
just waiting (Object.wait) : 0 : 39
I'll gladly give more info if anyone wants it.
Thanks in advance for any help!
-Brian Sorkin
Reasons for this:
1. Open connections in the application code that are not being released back
to the pool.
2. Waiting for a connection from the pool in the application code. This
would essentially lockup the execute threads.
can you post the thread dump here? and also whats the machine -
speed,processors, etc.
What version of WLS are you using?
/
sree
"Brian Sorkin" <br...@overture.com> wrote in message
news:3cabbaa8$1...@newsgroups.bea.com...
2)Make sure you add your JDBC drivers to the beginning of CLASSPATH in either setDomainenv.cmd or setEnv.cmd
3)What really helped was BEA support and playing with BEA's JDBC example that shows how to create and deploy and use a data source.