Kristian Waagan wrote:
I think a single connection is not expected to be shared between multiple threads simultaneously. Maybe the necessary synchronization is done at a lower level in the system.
This is not intended to be a complete answer, and perhaps I'm misunderstanding the thrust of your question, but I thought this quote from Appendix A of the old JDBC reference manual might be relevant/helpful: Since Java is a multithreaded environment, there seems to be no real need to provide support for asynchronous statement execution. Java programmers can easily create a separate thread if they wish to execute statements asynchronously with respect to their main thread. Some drivers may allow more concurrent execution than others, but developers should be able to assume fully concurrent execution. If the driver requires some form of synchronization, then the driver should provide it. In this situation, the only difference visible to the developer should be that applications run with reduced concurrency. For example, two Statement objects on the same connection can be executed concurrently, and their ResultSets can be processed concurrently (from the perspective of the developer). Some drivers will provide this full concurrency. Others may execute one statement and wait until it completes before sending the next one. My feeling is that the Derby implementation should strive to allow the greatest concurrency possible, but should perform the necessary synchronization automatically. thanks, bryan
