Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (herse.apache.org: domain of suresh.thalamati@gmail.com
 designates 66.249.82.229 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=qlcy3Es5zUSEtKFqmz2xPonkrqzTf0mwpSHEoJkmwUbijYp28+fikaPVVFfVCgTQ06/A9e9K2cMHBB8JlcXxDFc6RTvZ4irFf19WFqXztUlkMEmbWO+PhoE9xHGExOeTF/jtHEOBABHhYaGmfmkUs2K9lXhKhNEl81BIxjBvMyM=
Message-ID: <457A1B42.4040001@gmail.com>
Date: Fri, 08 Dec 2006 18:11:14 -0800
From: Suresh Thalamati <suresh.thalamati@gmail.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
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> <45632363.1080207@apache.org>
 <wjo8mz6jbox5.fsf@sun.com> <x1o3wt5noam1.fsf@sun.com>
 <456B065B.8090803@sbcglobal.net> <x7mz6cy6e6.fsf@Sun.COM>
 <456B5CDA.4060001@apache.org> <456B8527.5080103@sbcglobal.net>
In-Reply-To: <456B8527.5080103@sbcglobal.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Mike Matrigali wrote:
> 
> 
> Daniel John Debrunner wrote:
> 
>> Knut Anders Hatlen wrote:
>>
>>> Mike Matrigali <mikem_app@sbcglobal.net> writes:
>>>
< snip .?
>>
>> I'm not so sure. If it's simpler to keep page latching at the page 
>> level, then it would be better to remove the added complexity from the 
>> lock manager. What's the current state of IDEs/debuggers tracking down 
>> java synchronization deadlocks? Seems a better place to solve the 
>> problem.
> 
> And also does it help track down a deadlock that is half java 
> synchonization and half derby lock wait?
> 

I doubt IDES/Debuggers will helps if a user really hits a LATCH/LOCK 
or a LATCH/LATCH deadlock. Most of the time I would think they are not 
easily reproducible cases; All that user going to tell is DERBY is 
acting weird/frozen.

Recent jvms (jdk142 onwards) do tell if there is dead-lock on the 
monitor on a stack dump. I hope the stacks will give us some clues,
if the dead locks involves onlt latches or locks also.

If it is embedded , say in APP server I wonder how easy to get a
stack dump or how big it is going to be!

If some one is wondering , does these deadlocks  really happen, I 
found one : http://issues.apache.org/jira/browse/DERBY-1189
(but Mike seems to have got luckey with the repro)

Lock : LATCH, T1, Page(35,Container(0, 1728))
   Waiting XID : {385920, BaseContainerHandle:(Container(0, 1728))} , 
APP, CALL S
YSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1)
   Granted XID : {385920, BaseContainerHandle:(Container(0, 1728))}
. The selected victim is XID : 385920.


If we are removing Latching  out of LockManager for perfromance 
reasons, my preference also would be to handle at  the page level, 
instead of having yet another indirection.

As Mike mentioned , it would be nice to have a VTI that will show the 
latches in the system.


Thanks
-suresh