Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

CDO/Client

< CDO
Revision as of 04:31, 21 October 2007 by Stepper.esc-net.de (Talk | contribs) (Sessions)

TBD.

Introduction

CDOObjects represent the object instances of the models that your application deals with. Internally each such object is managed by a singleton CDOStateMachine. The state machine accurately transits objects and trees of objects through the states TRANSIENT, NEW, CLEAN, DIRTY, PROXY and CONFLICT. When a CDOObject is in one of the persistent states NEW, CLEAN or DIRTY the state machine associates a CDORevision that carries the current values of the modeled structural features. All revisions created or used in a CDOSession are shared by the CDORevisionMnager of that session. CDOObjects are only known to the CDO client. Only revisions are subject to (network) transfers between client and server.


CDOObject.png


CDOObject

Interface

A CDOObject is basically an EObject with a handful of additional read-only features as the following java code shows:

public interface CDOObject extends EObject
{
  public CDOClass    cdoClass();
  public CDOID       cdoID();
  public CDOState    cdoState();
  public CDOView     cdoView();
  public CDOResource cdoResource();
  public CDORevision cdoRevision();
}

The method names differ from the regular Java getter notation to make it less likely that name collisions with your model name space occur. To understand the details about the return types you should browse the JavaDoc.


Categories

While a user application always deals with EObjects the internal CDOStateMachine interacts with InternalCDOObjects. Depending on how the EObjects relate to the InternalCDOObjects there are a handful of different categories of CDOObjects, that is, implementations of InternalCDOObject. The following type hierarchy shows an example with the shipped test model installed:


InternalCDOObject.png


The main categories are:

  • Native objects extend CDOObjectImpl and fall into three sub categories:
    • Generated native objects directly extend CDOObjectImpl and result from slightly modified GenModels
    • Dynamic native objects are of class DynamicCDOObjectImpl and result from dynamic models added to a session's package registry
    • Resources are of class CDOResourceImpl (which also implements CDOObject and thus EObject!)
  • Legacy objects extend EObjectImpl and fall into two sub categories to interface the CDOStateMachine:
    • Unwoven legacy objects interface the state machine via an EMF adapter of class CDOAdapterImpl
    • Woven legacy objects interface the state machine via an AspectJ inter type declaration of class CDOCallbackImpl
  • Meta objects are the EModelElements contained in a session's package registry. Although their state is immutable they interface the state machine via CDOMetaImpl instances so that they can be referenced from ordinary objects.


From a CDO perspective native objects are the most efficient and full featured ones. They are the only category that combine the user application contract and the CDO state machine contract in a single object instance. Whenever possible you should generate your models to produce subclasses of CDOObjectImpl! The following table compares some important characteristics of the different object categories:

Model Type Native Legacy Meta
Dynamic Generated Unwoven Woven
Development
Artifacts
Ecore Unaffected N/A
Genmodel N/A Slightly modified Unaffected
Instance Interface CDOObject EObject EModelObject
State Machine Interface CDOAdapter CDOCallback CDOMeta
Location of
Internal Values
class DynamicCDOObject Java Byte Code
store CDOObject N/A
view CDOAdapter CDOCallback CDOMeta
id CDOSession
state N/A
revision
resource
Location of
Model Values
per CDOState
TRANSIENT EObject
NEW CDORevision EObject
and
CDORevision
DIRTY
CLEAN EModelObject


Client Infra Structure

CDOObjects do not just appear out of the dark. To create, load or access them you need, as usual in EMF, an instance of a Resource, here a CDOResource. The following diagram illustrates the CDO client infra structure concepts and their relation to CDOObjects:


InfraStructure.png


Sessions

A CDOSession is your connection to a single repository on a CDO server. Before you can do anything with CDO you need to open a session.


CDOSession.png


There are two ways to obtain a session:

  • If you already have an instance of a Net4j IConnector, which represents the physical connection to the server, at hand you can use the CDOUtil class:
IConnector connector = ...;
CDOSession session = CDOUtil.openSession(connector, "repo1");
session.setDisableLegacyObjects(...);
session.setReferenceChunkSize(...);
...
session.close();
  • You can also use a Net4j IManagedContainer, for example an extension point based IPluginContainer. The advantage of this approach is that you can leave all the wiring and configuration of the various components to the container which uses factories and element processors that you can contribute centrally via extension points:
CDOSession session = CDOSessionFactory.get(IPluginContainer.INSTANCE, "tcp://repos.company.com:2036/repo1");
...
session.close();

Views

TBD.

Transactions

TBD.

Read-Only Views

TBD.

Audit Views

TBD.

Resources

TBD.



Wikis: CDO | Net4j | EMF | Eclipse

Back to the top