Poor concurrency with Oracle JDBC drivers - Profiler indicates driver-issue
573854Apr 22 2007 — edited Apr 26 2007Hi,
I seem to be getting very poor concurrency with the Oracle jdbc drivers - and my profiling thus far indicates a synchronization problem in the driver.
I am using version 10.2.x.x thin drivers with oracle.jdbc.pool.OracleDataSource with no connection limit.
I am using Read-Committed tx isolation
My observations are:
- Our system is essentially message-driven (not jms) & and messages are processed by a threadpool. With a large batch of messags it doesnt seem to make any/much difference whether there are 1 or 10 threads in the threadpool (and the message processing is not cpu intensive at all).
- JProfiler shows huge contention on a Collections.SynchronisedMap monitor in the call to prepareStatement, executeQuery, executeUpdate, etc. That said, I dont have the exact call trace to an oracle class/line number - I dont know where this synchronized map is in the jdbc call (but I do know its in the jdbc call, not anywhere else).
- In a micro-test that executes a large number of "select 1 from dual" in parallel (10 threads, 10 connections) again JProfiler shows massive contention on a Collections.SynchronizedMap. 10 threads is much slower than 1 because of this contention.
Things I have tried/verified so far:
- I have tried the OCI drivers, but doesnt seem to make any difference (micro test is slower).
- I have verified that I do indeed get 10 physical connections from the connection pool.
- I have tried a different Pooling DataSource implementation (commons-db-pool) - but no perf difference & same thread contention showed in JProfiler.
- I havent had opportunity to try a different jdbc driver (inet) yet.
Does anyone have any ideas/suggestions?
I find it difficult to believe that this is a fundamental oracle jdbc problem - else I am sure I would not be the first to find it (and googling hasnt revealed it as a known problem). My initial assumption is that we are doing something silly - but thus far, I havent been able to identify what it is.
Cheers,
Nick