title: Connected Data Objects
text: # Connected Data Objects
  
  Connected Data Objects (CDO) is a free implementation of a Distributed Shared Model on top of the Eclipse Modeling Framework (EMF).
  
  With CDO, programmers can easily enhance existing EMF models in such a way that they can be stored and subsequently maintained in a central model repository. While object relational mapping against a JDBC data source on the server side is the shipped default, CDO provides for pluggable storage adapters that allow you to develop and use different mappers (like Hibernate- or OODB-based). On the client side, CDO provides a default integration with EMF, the Eclipse Modeling Framework, although other model integrations on top of the CDO protocol are imaginable as well.
  
  ## Model integration features
  
  * EMF integration at model level (as opposed to the edit level)
  * Support for generated models (just switch two .genmodel properties)
  * Support for dynamic models (just load .ecore file and commit to repository)
  * Support for legacy models (for compiled models without access to .genmodel)
  * Support for the Ecore meta model and descendants
  
  ## User interface features
  
  * Eclipse view for working with CDO sessions, transactions, views and resources
  * Package Manager dialog per session
  * Eclipse editor for working with resources and objects
  
  ## Client side features
  
  * Multiple sessions to multiple repositories on multiple servers
  * Multiple transactions per session
  * Multiple read-only views per session
  * Multiple audit views per session (an audit is a view that shows a consistent, historical version of a repository)
  * Multiple resources per view (a view is always associated with its own EMF ResourceSet)
  * Inter-resource proxy resolution
  * Multiple root objects per resource
  * Object state shared among all views of a session
  * Object graph internally unconnected (unused parts of the graph can easily be reclaimed by the garbage collector)
  * Only new and modified objects committed in a transaction
  * Transactions can span multiple resources
  * Demand loading of objects (resources are populated as they are navigated)
  * Partial loading of collections (chunk size can be configured per session)
  * Adaptable pre-fetching of objects (different intelligent usage analyzers are available)
  * Asynchronous object invalidation (optional)
  * Clean API to work with sessions, views, transactions and objects
  * CDOResources are EObjects as well
  * Objects carry meta information like id, state, version and life span
  * Support for OSGi environments (headless, Eclipse RCP, ...)
  * Support for standalone applications (non-OSGi)
  
  ## Network protocol features
  
  * Net4j based binary application protocol
  * Pluggable transport layer (shipped with NIO socket transport and JVM embedded transport)
  * Pluggable fail over support
  * Pluggable authentication (shipped with challenge/response negotiation)
  * Multiple acceptors per server
  
  ## Server side features
  
  * Pluggable storage adapters
  * Multiple repositories per server
  * Multiple models (packages) per repository
  * Multiple resources (instance documents) per repository
  * Expressive XML configuration file
  * Configurable storage adapter per repository (see below)
  * Configurable caching per repository
  * Clean API to work with repositories, sessions, views, transactions and revisions
  * Support for OSGi environments (usually headless)
  * Support for standalone applications (non-OSGi)
  
  ## DB store features
  
  * Supports all optional features of the CDO Server
  * Pluggable SQL dialect adapters
  * Includes support for Derby, HSQLDB, MySQL and Oracle (TBD)
  * Pluggable mapping strategies
  * Includes horizontal mapping strategy (one table per concrete class)
  * Includes vertical mapping strategy (TBD, one table per class in hierarchy)
  * Supports different mapping modes for collections
  