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: locking problem
Date Wed, 22 Jul 2009 15:30:38 GMT
"Robert J. Carr" <rjcarr@gmail.com> writes:

> Hi Knut-
>
> Thanks for the quick reply, and sorry to burden everyone, but I have a
> quick follow-up:
>
>> Yes, (2,43) tells you the page number (2) and the row number (43)
>
> Could you explain what the page number represents?

A table is stored in a file (aka conglomerate) which is divided into
pages, where each page usually is 4 KB. So the page number tells you in
which section of the file you will find the row, and the pair (page
number, row number) uniquely identifies the row within the file.

>> That's simple. :) Just don't commit your transactions:
>
> I did have a handful of setAutoCommit() methods but I removed all
> traces of them and I get the same problem in the same exact way.  I
> also logged the auto commit status and before the problem occurs it is
> set to TRUE.  Can you think of anything else that may cause a lock in
> this way?

If you retrieve a ResultSet, the transaction isn't auto-committed until
the ResultSet is closed, so leaving one open could cause locks to be
held.

-- 
Knut Anders

Mime
View raw message