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: [jira] Commented: (DERBY-733) Starvation in RAFContainer.readPage()
Date Sat, 17 Dec 2005 00:34:10 GMT
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


Mime
View raw message