db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Releasing latches when waiting for locks. When and why?
Date Mon, 20 Nov 2006 15:04:32 GMT
Bryan Pendleton <bpendleton@amberpoint.com> writes:

>> When this method is used, the specified latch will be
>> released if the lock cannot be obtained immediately, and that page
>> will be re-latched when the lock has been obtained.
>
> I'm just guessing here ...
>
> I think that there are some fairly advanced Btree traversal algorithms,
> in particular situations in which you are reading backward through a
> Btree which may be undergoing concurrent structural modifications by
> others, in which a primitive operation like the one you describe is crucial.
>
> So perhaps this method was included in the Store in preparation for some
> access method techniques which haven't yet been implemented?

Thanks Bryan, that could be the case. I have done some more
investigation and it seems like the method is only called when a
B-tree container is opened with a lock policy. It also seems like the
B-tree containers always are opened with a null/NoLocking lock policy
(regardless of isolation level) and therefore the method is never
called.

However, I made an interesting discovery in
B2IRowLocking3.lockRowOnPage(). It uses the following procedure for
locking a row while holding a latch:

  1) Try to lock the row with timeout == NOWAIT.
  2) If the lock couldn't be obtained without waiting, manually
     release the latch and try to lock the row with a normal timeout.

I don't see why this couldn't be done similarly in the few cases that
maybe some time in the future will need that functionality. Perhaps we
could change those calls and reduce some of the complexity of the lock
manager? I generally prefer to optimize for the most common and/or
least complex cases, and let the more complex cases pay the cost of
extra complexity themselves. If the more complex cases are only for
possible future use, I think that point is even more valid.

Also, I'm not sure that using the lock manager for latching is optimal
in the first place. The description of Derby's B-tree implementation
[1], says that the implementation is similar to ARIES/IM [2].
According to the ARIES/IM report,

  "Acquiring a latch is cheaper than acquiring a lock (in the
  no-conflict case, 10s of instructions versus 100s of instructions),
  because the latch control information is always in virtual memory in
  a fixed place, and direct addressability to the latch information is
  possible given the latch name. Since each transaction holds at most
  2 or 3 latches simultaneously (...), the latch request blocks can be
  permanently allocated to each transaction and initialized with
  transaction ID, etc. right at the start of that transaction. On the
  other hand, storage for individual locks may have to be acquired,
  formatted, and released dynamically, and more instructions need to
  be executed to acquire and release locks."

In Derby, latching is cheaper than locking, but not nearly as cheap as
the ARIES/IM report suggests. I have done some measurements and come
to the conclusion that setting one latch is about half the cost of
setting one lock. The reason why latching is so expensive in Derby, is
that it basically uses the same code as the locking, and therefore
gets some of the extra overhead caused by the locks' dynamic nature. I
think it would be a great improvement if latching of pages didn't have
to go through the lock table and instead just set a flag on the page
object.

Footnotes: 
[1]  http://db.apache.org/derby/papers/btree_package.html

[2]  http://www.almaden.ibm.com/u/mohan/RJ6846.pdf

-- 
Knut Anders

Mime
View raw message