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

Much thanks.
- Adam