Montag, 31. Juli 2017

Using Eclipse CDO as a lightweight ORM solution in web applications


For one of my projects I had to decide for an object relational mapping (ORM) solution to be used in a web environment. There is not much to think about when deciding which framework to use. Yet, I wanted to try out Eclipse CDO [1] as an alternative to, for example, hibernate.
The project is powered by CDO since a year, now. And it has proven to be a lightweight ORM solution. No JPA annotations, just design your EMF model, create instances and let CDO handle the rest...

A full request/response cycle

The following sketch shows the involved steps when a user (HTML5 client/browser) sends a HTTP request to a service that consumes the CDO storage.
Request/Response process

The web application is driven by (JAX-RS) REST services, so any call/request is served by the appropriate REST service. 
For each call which requires DB access, a new CDO transaction is opened, the request is processed, the result is converted to JSON and the transaction closed/committed.
Conversion of EMF model instances is done using Eclipse Texo [2] in most scenarios, but special view models are also created using a JSON java library like org.json [3].

The overall setup of the CDO server/backend:
  • CDO DBStore with embedded H2 RDBMS
  • disabled auditing, disabled branching (not needed by project)
  • one resource per user, central meta data resources (for example, user accounts, roles, permissions management), managed in different resource folders
    • simulation of a document oriented database
    • simplifies authorization a lot
  • nginx proxy for simple HTTPS setup
  • OSGi environment with embedded Jetty, packaged using a maven/tycho enabled Eclipse RCP product build
  • a very limited virtual host (for now): 512 MB RAM, single core Xeon CPU, Ubuntu 16.04 server
Have you ever considered using CDO as an ORM solution? Or are you already using it in a web context? What are your experiences?

[1] Eclipse CDO:
[2] Eclipse Texo:


  1. I am currently using CDO in a very similar setting (web application, REST interface, OSGI, Jetty).
    - I create one transaction per thread (not per request) although I am not sure if creating a transcation comes with a big overhead
    - A problem we have not solved so far is the evolution of the model, i.e. how can we upgrade existing data-model in case the meta-model changes
    - Our UI is based on Angular 2, hence we use the EMF models additionally for generating type script classes from them, which reduces problems at the interface between UI and backend
    - The pattern we acess the data so far is in "browsing style", drilling down from high-level folders to leaves. For this access pattern the CDO setting works well also from a performance point-of-view. I wonder how this changes for other access patterns (e.g. search queries)

    1. Thanks for your great feedback, Maximilian!

      1. I have not encountered any performance issues concerning one transaction per thread or request, if there are any concerns, then I am sure the DBStore can be enhanced to use the native connection pool mechanims many JDBC drivers already provide or have built-in

      2. I have found a working approach for my use case: stream each resource into a XML database, transform the XML data and adapt it to the new meta model (using XQuery), stream back into a new repository, start the CDO server using the new repository...

      3. nice :-)

      4. In my case, each user has its own resource, so I also traverse that resource in top-down direction when searching for a specific entity. When using custom SQL queries you have to make sure you do not return any entities outside the user's resource.