db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: [jira] Commented: (DERBY-938) ContextManager needs to be optimized
Date Fri, 10 Feb 2006 01:34:38 GMT
Dyre.Tjeldvoll@Sun.COM wrote:

> Provide specalized accessor method to get the most recently pushed ExecutionContext and
StatementContext.
> This lets clients of the ContextManager class access these Contexts
directly without going through the HashMap.

This does break the intended model of the ContextManager in that it is
meant to be independent of other code in the system, like most of the
services. Thus, in theory, a store system could be built without
dragging in any language code, now such a system would drag in language
code.

While that may not be a goal of Derby, starting to link independent
modules together starts down the the rocky path of losing all modularity.

Looking at this fix, and I have similar concerns about DERBY-210, I
would encourage folks to do two things:

   1) Come to the list early with your thoughts/direction on solving an
issue. This is open source development, the more eyes on a problem as
well as the code can only benefit Derby. Take advantage of the folks
that have been working on the product for nearly ten years, take
advantage of all the new eyes with fresh ideas we have.

   2) Consider splitting patches that do N things to fix an issue into N
independent patches if possible, or some number > 1. Some of the changes
in the patch are good by themselves, they don't have to be linked with
other changes that have modularity concerns. E.g. replacing use of a
synchronized collection with an unsynchronized one. Incremental
development is a great model.


Dan.




Mime
View raw message