Understanding the Technical Background
This article explains the relationship between the main concepts that are exposed in the CDO User Interface and their underlying technical core concepts.
Table of Contents
|1||Technical Background of Model Elements|
|2||Technical Background of Repositories|
|3||Technical Background of Checkouts|
|4||Technical Background of Sessions|
|5||Technical Background of Views|
|6||Technical Background of Transactions|
|7||Technical Background of the Compare Integration|
Model elements are EObject EObjects.
EObjects are instances of concrete EClass EClasses, sometimes referred to as model element types.
EClasses are contained by EPackage EPackages, often referred to as meta models and sometimes less specifically as just models.
EPackages are registered in the Registry EPackage.Registry.
The term "native model" refers to an EPackage that is generated with some CDO-specific options to fully exploit CDO's unprecedented characteristics with respect to scalability and performance.
Native model elements are lazily loaded when they are needed and automatically garbage-collected when they are no longer needed. Repositories with native model elements can scale to arbitrary sizes. Clients may not be able to load all objects of these large repositories at the same time, but they are able, for example, to iterate all objects of a large repository without worrying about memory management.
Technically native model elements are instances of the Java class
Generating or regenerating an EPackage with the CDO-specific options (as explained in Native Models) is not always possible, for example if an EPackage has already been generated by a third party. In these cases the original generated EPackage can still be used with CDO; and is then referred to as a "legacy model".
The integration of legacy models with CDO is based on CDOLegacyAdapters.
Legacy model elements are not loaded lazily and not automatically garbage-collected.
It is not strictly necessary for an EPackage to be generated into Java code to be used with CDO. An EPackage can also be loaded dynamically at runtime (see Creating an Ecore Model for an example of the XML representation of an EPackage).
Technically dynamic model elements are instances of the Java class DynamicCDOObjectImpl.
Dynamic model elements share the characteristics of native model elements with respect to enhanced scalability and performance,
The term "repository" is a slightly ambiguous in CDO, as it may refer to both a server-side / core-level
and a client-side / UI-level
An IRepository is a "real" repository backed by a physical database (of one of various
forms). In production
such repositories typically exist in a CDO server
that provides remote access through one or more
The Operator's Guide explains how to configure and operate a CDO server.
A CDORepository is more of a configured connection to a "real" IRepository, which
is remembered across Eclipse sessions. In the case of a local repository (connection)
an internal IRepository is created with an
H2 database stored on the local disk.
connected CDORepository maintains a single
CDOSession to the underlying IRepository.
This session is shared by all
transactions of all
from that CDORepository.
CDOCheckout is not necessarily a physical copy of a repository on the local disk (only offline checkouts
maintain a locally replicated repository copy). More generally they represent the following two aspects:
CDORepositoryas a way to use the internal
CDOSessionof that CDORepository.
time stamp, that is needed to open
CDOTransactionson the shared CDOSession of the referenced CDORepository
A CDOCheckout internally maintains a main CDOView that is, for example, used to provide the resources and model elements that
are displayed in the Project Explorer. As objects that are provided by CDOViews are read-only
any modification action on these objects, for example as offered in the various context menus or triggered by drag and drop events,
transactional copies of the objects in the context of a background thread.
Each model editor opened on a resource or model element of a CDOCheckout typically
(but depending on the implementation of that editor) maintains its own CDOTransaction to isolate changes and locks from other
views and transactions. Typically the save action of a model editor delegates directly to the
method of its associated CDOTransaction.
CDOSession is the technical representation of a
CDOProtocol connection to an
On the transport level this connection is provided by an
CDOView is a technical facility that provides a client application with all the models and model elements in a repository
for a specific
point in time and in a specific
The model elements provided by a CDOView are
CDOTransaction is a technical facility that provides a client application with all the latest models
and model elements in a repository in a specific
The model elements provided by a CDOTransaction are writable.
Changes to these model elements must be
committed to make them
persistent in the repository and to distribute them to the views and transactions of other users.
With CDO both EMF Compare editors and EMF Merge editors are instrumented to utilize an optimized CDO mechanism in order to compute
matches in a very efficient and scalable way. This mechanism consists of special
and remote database queries to determine and deliver the
object IDs that are involved in all changes
between two different
CDOBranchPoints. The response times depend on the implementation of the
The response time of the default implementation, the DBStore, scales more
with the sizes of the stored meta models (i.e., the number of concrete EClass EClasses) than with the sizes of the stored models
(i.e., the number of EObject EObjects).