Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <45632363.1080207@apache.org>
Date: Tue, 21 Nov 2006 08:03:47 -0800
From: Daniel John Debrunner <djd@apache.org>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: Releasing latches when waiting for locks. When and why?
References: <wjo8bqn6t7s6.fsf@sun.com> <455E4FDF.5030600@amberpoint.com>
 <wjo81wnytb0f.fsf@sun.com> <4561FE49.2000901@sbcglobal.net>
 <wjo864d8dhuy.fsf@sun.com>
In-Reply-To: <wjo864d8dhuy.fsf@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Knut Anders Hatlen wrote:
> Mike Matrigali <mikem_app@sbcglobal.net> writes:
> 
>> Having said that it would be interesting if someone had time to
>> implement a higher performance latch implementation and plug it in
>> and see how much it helps.  It would decrease the total time spent
>> in lock manager.
> 
> Ok, a new experiment: I removed the calls to LockFactory.latchObject()
> and LockFactory.unlatch() in BasePage. Instead, I let BasePage check
> manually whether it was latched and use wait/notifyAll if it was. The
> patch (which is very simple) is attached.
> 

The original decision to use the lock manager for the latches was to 
enable easier debugging of deadlocks during the early development of the 
store code. A local latch implementation, like Knut Anders made, does 
make a lot of sense, but does leave derby open to undetectable 
deadlocks. Given the performance gains it probably is worth the risk, 
especially since I don't think we've seen a problem with latch ordering 
for many years.

Dan.