db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: timeouts and long-running transactions
Date Fri, 02 Jan 2009 13:55:40 GMT
Adam B <cruxic@gmail.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:
> 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?

No, it will only lock rows in the tables that it accesses. SELECT
operations against tables that the long-running transaction doesn't
touch, should not run into lock conflicts with the long-running
transaction.

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,

-- 
Knut Anders

Mime
View raw message