Thanks for the info Knut! After enabling those diagnostic properties I found that the big transaction was, in fact, updating the table in question.
No, it will only lock rows in the tables that it accesses. SELECTAdam B <email@example.com> writes:
> 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:
> 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
operations against tables that the long-running transaction doesn't
touch, should not run into lock conflicts with the long-running
Running your application with derby.locks.monitor=true,
derby.locks.deadlockTrace=true and derby.language.logStatementText=true
will give you more information about which transactions are involved in
the lock conflict and which statements they have executed.
Hope this helps,