Hello all, I'd like to confirm that the behavior I'm seeing is expected:
We have a multithreaded application against an embedded derby database (10.4). While one thread is chugging away doing many thousands of inserts inside a transaction other threads are getting SQLExceptions about "a lock could not be obtained withing the time requested". The exceptions consistently happen trying to do a SELECT from a table that is not modified by the big transaction in the other thread so I don't think we are dealing with a deadlock. If it matters, we are using the default isolation level: TRANSACTION_READ_COMMITTED. I did some searching and found this in the derby documentation: Even if a transaction is not involved in a deadlock, it might have to wait a considerable amount of time to obtain a lock because of a long-running transaction or transactions holding locks on the tables it needs. [http://db.apache.org/derby/docs/10.2/devguide/cdevconcepts89097.html] Is it true that a long-running transaction will essentially lock the entire database? Much thanks. - Adam
