this is for holding javascript data
Bhathiya added Section_Apache_Derby_Architecture_Before__.tex
about 8 years ago
Commit id: 459f45417288cefc45dc1d28fedf9049e40c9cfc
deletions | additions
diff --git a/Section_Apache_Derby_Architecture_Before__.tex b/Section_Apache_Derby_Architecture_Before__.tex
new file mode 100644
index 0000000..7583b3b
--- /dev/null
+++ b/Section_Apache_Derby_Architecture_Before__.tex
...
\Section {Apache 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.
A module in Derby is a set of discrete functionality,
such as a lock manager, JDBC driver, indexing method
etc. A module’s interface is typically defined by a set of
Java interfaces. For example the java.sql interfaces define
a interface for a JDBC driver. All callers of a module
do so purely through its interface to separate api from
implementation. A module’s implementation is a set of
classes that implement the required behavior and interfaces.
Thus a module implementation can change or be replaced
with a different implementation without affecting the callers’
code. Modules are either system wide (shared) or per-service
with a service corresponding to a database.
