Daniel John Debrunner <[EMAIL PROTECTED]> 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
