# Understanding the Technical Background

Author: Eike Stepper

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
| 1.1 | Native Models
| 1.2 | Legacy Models
| 1.3 | Dynamic Models
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

## 1 Technical Background of Model Elements

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.

See Also:

- EMF Developer Guide

### 1.1 Native Models

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 `CDOObjectImpl`.

See Also:

- CDO Scalability
- Preparing EMF Models for CDO

### 1.2 Legacy Models

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.

### 1.3 Dynamic Models

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,

## 2 Technical Background of Repositories

The term "repository" is a slightly ambiguous in CDO, as it may refer to both a server-side / core-level `IRepository` and a client-side / UI-level `CDORepository`.

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 `ITCPConnectors`. 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.

Internally a `connected` CDORepository maintains a single `CDOSession` to the underlying IRepository. This session is shared by all `views` and `transactions` of all `checkouts` from that CDORepository.

See Also:

- Managing Repositories
- Technical Background of Sessions

## 3 Technical Background of Checkouts

A `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:

- A reference to a configured `CDORepository` as a way to use the internal `CDOSession` of that CDORepository.
- The `CDOBranchPoint` information, i.e., `branch` and `time stamp`, that is needed to open `CDOViews` and `CDOTransactions` on 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, operates on `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 `commit` method of its associated CDOTransaction.

## 4 Technical Background of Sessions

A `CDOSession` is the technical representation of a `CDOProtocol` connection to an `IRepository`. On the transport level this connection is provided by an `IConnector` / `IAcceptor` pair.

See Also:

- CDO Sessions View
- Technical Background of Views
- Technical Background of Transactions

## 5 Technical Background of Views

A `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 `branch`. The model elements provided by a CDOView are `read-only`.

See Also:

- Technical Background of Sessions
- Technical Background of Checkouts

## 6 Technical Background of Transactions

A `CDOTransaction` is a technical facility that provides a client application with all the latest models and model elements in a repository in a specific `branch`. 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.

See Also:

- Technical Background of Sessions
- Technical Background of Checkouts

## 7 Technical Background of the Compare Integration

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 `client-server protocol` 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 `backend storage`. 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).

Copyright (c) 2014 Eike Stepper (Berlin, Germany) and others.
All rights reserved. This program and the accompanying materials are made available under the terms of the Eclipse Public License v1.0 which accompanies this distribution, and is available at http://www.eclipse.org/legal/epl-v10.html