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.Is it true that a long-running transaction will essentially lock the entire database?