db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dag.Wan...@Sun.COM (Dag H. Wanvik)
Subject Re: Derby Statements
Date Fri, 29 Jan 2010 16:33:28 GMT
Ronald Rudy <ronchalant@gmail.com> writes:

> In my code as it is written today I don't use transactions.  When
> I've enabled transactions for the thread iterating over resultsets,
> with various isolations, it didn't seem to help - it either blocked
> out others or never started. 

Derby is always transactional, so even with autocommit, when you open
a read-only result set for iterating over it, any read locks it sets
for a row would block another connection trying to modify that row
(Update or delete). If you use repeatable read, the locks will not be
released for the rows you have already visited as long as the
transaction is live, so this would significantly increase the chances
of update connections blocking for as long as the iteration is going
on.  By moving to read committed isolation level, you should (AFAIK)
only have one row level read lock set for the row the cursor is
presently positioned at. It would be interesting to know to do the
kind of debugging Bryan suggested to determine why the update
tranactions block, if you could find the time :)


View raw message