Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
From: "Stefan Guggisberg" <stefan.guggisberg@gmail.com>
To: <jackrabbit-dev@incubator.apache.org>
Subject: implementation notes
Date: Fri, 17 Sep 2004 17:18:42 +0200
Message-ID: <CBEKLHGHNPNBGFAGPLHMOEDNCHAA.stefan.guggisberg@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0033_01C49CDA.61585900"
Importance: Normal

------=_NextPart_000_0033_01C49CDA.61585900
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

folks,

i tried to provide a very general overview of the current implementation
to help you getting started with the code.

i am aware that i don't really shine at describing complex technical matters
in a coherent way but i hope it's nevertheless somehow usefull ;)

questions, comments, suggestions etc are very welcome.

now to the implementation notes (can also be found in
/src/java/org/apache/jackrabbit/core/package.html):

The following classes implement the 'core' JCR interfaces Item, Property,
Node, Session, Workspace and Repository:

  a.. ItemImpl
  b.. PropertyImpl
  c.. NodeImpl
  d.. SessionImpl
  e.. WorkspaceImpl
  f.. RepositoryImpl
A SessionImpl instance is created upon successfully login to the Repository
(see Repository#login(Credentials, String)).
A Session is always tied to the Workspace specified in the
Repository#login(Credentials, String) call. A workspace represents a
persistent tree of repository items (i.e. Nodes and Propertys). The items in
a workspace are 'visible' to all sessions accessing it (subject to their
access rights, of course). A WorkspaceImpl instance represents a specifc
workspace as seen by the session that accesses it.

Every repository item is uniquely identified by its ItemId. The id of a node
(NodeId) consists of the node's uuid. The id of a property (PropertyId)
consists of the parent node's uuid and the qualified name of the property.

Every SessionImpl instance has its own ItemManager. The per-session instance
of ItemManager acts as item factory (i.e. it creates NodeImpl and
PropertyImpl instances) and provides item access by item id and item
caching.

The data (or state) of an item is represented by the following classes in
the subpackage state:

  a.. ItemState
  b.. PropertyState
  c.. NodeState
There's one PersistentItemStateManager for every workspace. It provides item
state caching and it guarantees that there's only one (persistent) item
state instance for any distinct item id in that workspace.
Every session has its own SessionItemStateManager that consists of the
session's TransientItemStateManager and the workspace's
PersistentItemStateManager.

Each item (i.e. NodeImpl and PropertyImpl) instance is holding an ItemState
instance. When e.g. a session is modifying a property by changing the
property's value, a new transient item state is created by the session's
TransientItemStateManager. This transient state is actually wrapping the
(old) persistent state (copy on write). The PropertyImpl's state is then
replaced by the new transient state.

Transient (i.e. unsaved) modifications are 'session-local', i.e. they are
not visible to other sessions. When the modifications are saved they become
instantly visible to all sessions accessing the same workspace.


that's all for the moment.

cheers
stefan

------=_NextPart_000_0033_01C49CDA.61585900--