To rephrase the question: should I avoid sharing instances of classes which implement java.sql.Connection between different threads?
To rephrase the question: should I avoid sharing instances of classes which implement java.sql.Connection between different threads?
This is rather an old thread, but for those who are looking for an answer regarding Microsoft SQL Server, here is the answer:
SQLServerConnection is not thread safe, however multiple statements created from a single connection can be processing simultaneously in concurrent threads.
and
SQLServerConnection implements a JDBC connection to SQL Server.
From all the above, you can share statements but not Connections, and in case you need a connection in each thread, you may use a thread pool.
Read more here
Oracle JDBC and Multithreading docs:
Because all Oracle JDBC API methods are synchronized, if two threads try to use the connection object simultaneously, then one will be forced to wait until the other one finishes its use.
So it may be safe in Oracle case but concurrent access would suffer from bottleneck.
We had ArrayOutOfBoundsException on the Websphere statement cache of it's pooleddatasource, and we had to disable that cache.
We had a treatment that was blocking itself.
All of that because of current access to the connection, so the conclusion by real life practice, is that you must not do that.