Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <43F11381.1040004@apache.org>
Date: Mon, 13 Feb 2006 15:17:21 -0800
From: Daniel John Debrunner <djd@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: [jira] Commented: (DERBY-938) ContextManager needs to be
 optimized
References: <311124971.1139501158598.JavaMail.jira@ajax.apache.org>
 <43EB7FB5.1000107@sbcglobal.net> <x1o3oe1ge4vi.fsf@sun.com>
 <43EBEDAE.6060604@apache.org> <x1o3zmkvdltd.fsf@sun.com>
In-Reply-To: <x1o3zmkvdltd.fsf@sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dyre.Tjeldvoll@Sun.COM wrote:

>>>>>>"DJD" == Daniel John Debrunner <djd@apache.org> writes:
> 
>     DJD>    2) Consider splitting patches that do N things to fix an
>     DJD>       issue into N
>     DJD> independent patches if possible, or some number > 1. Some of
>     DJD> the changes in the patch are good by themselves, they don't
>     DJD> have to be linked with other changes that have modularity
>     DJD> concerns. E.g. replacing use of a synchronized collection
>     DJD> with an unsynchronized one. Incremental development is a
>     DJD> great model.
> 
> I don't mind splitting the patch into smaller pieces if that makes it
> easier to review it. Having said that, I don't really understand how
> the patch can be split in such a way that each sub-patch becomes
> meaningful by itself. All the ways of splitting the patch that I can
> think of seems to leave each part with "baggage" that only makes sense
> if viewed together with the other parts. But again, if it aids the
> reviewers... 

I don't mean to get people to split patches for no reason, but into
logical pieces. From a high level I can see that this patch has at least
two independent changes:

1) Change the base collection for the context manager from a
synchronized to an unsynchronized.

2) Optimize the context manager sor statement and execution contexts by
pushing language specific concepts into the ContextManager.

To my eyes:

1) seems like a good thing to do regardless of 2) and could be done
before or after 2). Truly independent.

2) on the other hand is taking a module that is meant to be independent
of the language layer and pushing language specific concepts into it.
This one seems like it could do with more discussion, is the context
manager really the correct place to solve this, maybe the system should
be reworked so this functionality is in the language connection context?

Dan.