[EMAIL PROTECTED] 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.
