deletions | additions       diff --git a/Section_Apache_Derby_Architecture_Before__.tex b/Section_Apache_Derby_Architecture_Before__.tex  index d9baa23..7aa6d70 100644  --- a/Section_Apache_Derby_Architecture_Before__.tex  +++ b/Section_Apache_Derby_Architecture_Before__.tex 
...
\Section {Apache Derby Architecture}  \subsection{Derby Architecture}  Before going in to the details of Derby Optimizer lets look at the Apache Derby architecture. If we consider the module view of Derby architecture it is a system comprised of a monitor and a collection of modules. The monitor is code that maps module requests to implementations based upon the request and the environment. For example with JDK  1.3 the internal request for a JDBC driver the monitor selects Derby’s JDBC 2.0 implementation, while in JDK 1.4 the driver is the JDBC 3.0 implementation. This allows Derby to present a single JDBC driver to the application regardless of JDK and internally the correct driver is loaded. 
...
Services of Derby architecture are utility modules such as lock management, cache management, error logging etc. The services/cache component is a general purpose  caching mechanism that simply caches objects that implement the cacheable interface. It is used by the store for buffer caching, but it is also used to cache compiled plans for  SQL statements, open containers and their file descriptors, string conversions, table descriptors and maybe more. The interface/implementation split ensures that the cache algorithm  is not known by the users of the cache and can be changed with affecting them. The current algorithm is a ”clock or ring” based algorithm. \subsection{Derby Optimizer}  After introducing the Derby architecture now we can present the Derby optimizer which is used by the SQL compilation under the SQL layer. The optimizer currently only considers left-deep trees. That is, when looking at joins, it doesn’t consider join nodes to the right of other join nodes  - the nodes. The  join trees it considers are skewed to the left. Bushy trees where the join tree can take any shape are harder to implement but are often useful for big multi-way decision-support decision  support  joins. During optimization the join order is represented as an array of Optimizables. The first element in the array is the leftmost table in the join tree, and the successive elements in  the array are the joining tables in the left-deep tree. The optimizer does an exhaustive search of query plans, going through all the join orders and, for each join order, all of the access paths for that order. It remembers the cheapest complete plan it has found so far, and does cost-based search space pruning. That is, it doesn’t consider plans that are more expensive that the best plan found so far. The optimizer goes through the search space depth-first.