Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Sat, 17 Dec 2005 01:34:10 +0100
From: Knut Anders Hatlen <Knut.Hatlen@Sun.COM>
Subject: Re: [jira] Commented: (DERBY-733) Starvation in
 RAFContainer.readPage()
In-reply-to: <43A327D6.8080507@debrunners.com>
To: derby-dev@db.apache.org
Message-id: <874q587e9p.fsf@sun.com>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)
References: <909576820.1134603346924.JavaMail.jira@ajax.apache.org>
 <43A31752.80806@sbcglobal.net> <43A327D6.8080507@debrunners.com>

Daniel John Debrunner <djd@debrunners.com> writes:

> Mike Matrigali wrote:
>> You have raised some issues about this patch.  In the apache
>> commit/review model should I be raising a vote on the patch.  I
>> think this is basically do you feel strongly enough to vote -1
>> on such a vote.
>
> Any patch implictly has a vote, there is no need to raise such a thing.
> If I wanted to vote -1 I would do so.
>
>> I don't think Knut plans on building a separate module for this
>> locking stuff, at least not until it is used in more than one place.
>> He should comment.

That's correct, I don't plan on doing that. Not right now, at
least. Of course, if someone voted -1 the plans would probably
change. ;)

>> I am ok with the patch, and would go foward with his subsequent
>> patch recently submitted as it addressed some of my concerns (I have
>> not had a chance yet to review it).  I agree the separate module
>> approach is
>> better, but that is not what was submitted.  I believe I would
>> not commit a proliferation of the same kinds of changes in multiple
>> files.
>> 
>> I am hoping that this patch leads to more work in this area, identifying
>> the next bottleneck and next change and it may become clearer what major
>> changes need to happen.
>
> Agreed, though it does concern me a little that there is an existing
> mechanism for ensuring single threaded access to an object with queuing.
>  It seems that one of the reasons it was not used was that someone had a
> question about if it could be used, but that question was not rasied on
> the list until after the patch was submitted and committed.
>
> I don't want to see a trend where people add code that replicates
> existing internal functionality because they don't understand the
> existing functionality and never ask about it on the list.

I admit that you are correct when you are saying that I don't
understand the functionality of the lock manager. However, saying that
I never asked about it on the list is not entirely true. I did post a
description of the problem on the list. And I did post a description
of what functionality was needed to fix the problem and how I planned
to implement it. Using existing functionality is of course a much
better solution than the ugly hack I came up with, but I never hid my
intentions from the list. If someone knew that Derby already had that
kind of functionality, nothing prevented them from letting me know.

-- 
Knut Anders