% File: locality6.tex
% Status: Last edit by Florian 29-DEC-90
%
\section{Exploiting Object Locality}
\label{sec:example}

At first glance, the introduction of locality information in
database systems seems to merely complicate the tasks of programmers
and users: They lose the illusion of a uniform (persistent) store
and have to be aware of the repository structure and the restrictions
imposed by reachability constraints.\footnote{Note that a
partitioned object store with the trivial reachability constraint
$\mu(R)=\cal R$ for all $R \in \cal R$ would re-establish this
illusion.} However, since we regard {\em operational support\/} for
large scale data structures with persistence, access optimization,
access control, garbage collection, concurrency control and recovery 
as an essential property of data-intensive applications, language
mechanisms for locality control seem to be required.

% general problem solving approach

Specifically, we envisage the exploitation of repositories and
object locality
\begin{itemize}%
\item to express organizational and logical clusterings of objects via
repositories with suitably selected dependency sets;
\item to associate non-functional attributes with
repositories (e.g., physical placement on devices and network nodes,
persistence mechanisms, access rights and ownerships, concurrency
control and recovery policies, object faulting strategies);
\item to equip module interfaces with locality specifications  
constraining the utilization of exported references;
\item to support the removal and the modification of entire
repositories by explicit information about dependent repositories;
\item to improve the performance of ``global'' object store operations
(e.g., garbage collection, address translation, backup, recovery)
by exploiting the locality within individual repositories.
\end{itemize}

Another interesting property of our type system is the fact that a
non-empty locality tag $\pi$ in a function type specification
$\tau_1\funtype{\pi}\tau_2$ indicates that the evaluation of a function
of this type depends on side effects in repositories $\pi$, an
information that is particularly valuable for query optimizers in 
database systems \cite{HFLP89}.

The generalization of type inference techniques to incorporate
object locality, as outlined in section~\ref{sec:typeinf}, will allow a
smooth coexistence of ``querying'' users unaware of reachability
constraints and programmers making heavy use of locality information to
develop modular application code amenable to system evolution and
performance optimization.