db4o

Das db4o-Projekt begann im Jahr 2000 unter Führung von Carl Rosenberger. Entwickelt wurde db4o von der Firma db4objects, Inc., die 2004 mit Hilfe von Investoren wie Mark Leslie (VERITAS Software), Vinod Khosla (Sun Microsystems) und Jerry Fiddler (Wind River) gegründet wurde.

Im Dezember 2008 wurde die Datenbanksparte an Versant verkauft.[2]

db4o wird derzeit nicht mehr weiterentwickelt. Die Webseite www.db4o.com ist nicht mehr erreichbar, und die letzte Änderung bei Sourceforge war 2015, weiterhin gehört Versant seit Dezember 2012 zu Actian.[3]

db4o wurde seit 2004 wahlweise unter der GPL als freie Software lizenziert oder unter einer kommerziellen Lizenz, die die Verwendung in nicht-GPL-Projekten erlaubt. Daneben gab es eine Classpath-ähnliche Lizenz, die es erlaubt, db4o in Open-Source-Projekte zu integrieren, die nicht db4o / GPL konform sind.

• Neben dem kleinen Speicherbedarf für die Programmbibliothek ist der Bedarf an Arbeitsspeicher zur Laufzeit ebenfalls gering und überschreitet normalerweise 1 MB nicht.
• db4o kann nicht von außen administriert werden. Sämtliche Einstellungen müssen über den Programmcode vorgenommen werden.
• Die Datenbank kann in gemischten Umgebungen eingesetzt werden: Beispielsweise können zwei in C# oder Java programmierte Client-Anwendungen gemeinsam auf eine Datenbank zugreifen, die von einer in Java oder C# programmierten Server-Anwendung betrieben wird. Mit Hilfe des Alias-Features von db4o können dabei Klassennamen umbenannt werden, was beispielsweise wegen der unterschiedlichen Benennungskonventionen notwendig ist.
• Eine der wichtigsten Vorteile von db4o: Objekte können gespeichert werden, ohne dass hierfür besondere Vorkehrungen getroffen werden müssen. Es ist weder notwendig, die zu speichernden Klassen von speziellen Oberklassen abzuleiten, noch müssen spezielle Schnittstellen implementiert werden. Auch eine Anreicherung des Bytecodes, wie sie beispielsweise die Aspektorientierte Programmierung verwendet, ist nicht nötig. Die Objekte können dabei beliebige Typen enthalten und zudem beliebig tief verschachtelt sein.
• Mit dieser Eigenschaft ist es möglich, Persistenz mit wenig Aufwand umzusetzen.

API (application programming interface) bezeichnet die Programmierschnittstelle, mit der die Datenbank programmiert wird. Dabei zeigt sich, dass der Unterschied zu anderen Programmen wie Hibernate oder JPA / EJB nicht allzu groß ist.

Ein einfaches Codebeispiel, das zusammenhängend ausgeführt werden sollte:

   // Öffne eine Datenbank
   ObjectContainer db = Db4o.openFile("C:/beispiel.db");
   try {
      // Speichere zwei Personen
      db.store(new Person("John Doe","TOP INC",45));
      db.store(new Person("Clara Himmel","BB Radio",30));
      // Iteriere über alle Personen
      ObjectSet result = db.queryByExample(new Person());
      while (result.hasNext()) {
          System.out.println(result.next());
      }
      // Verändere eine Person
      result = db.queryByExample(new Person("Clara Himmel"));
      Person found = (Person) result.next();
      found.setAge(25);
      db.store(found);
      // Lösche eine Person
      db.delete(found);
      // Schreibe die Änderungen fest
      db.commit();
   }
   finally {
      // Schließe die Datenbank
      db.close();
   }

• Ähnlich zu EJB / JPA (dort EntityManager) wird zuerst ein ObjectContainer als Objektmanager erstellt. Dieser Container kann entweder auf eine Datei verweisen oder in einer Client-Server-Architektur auf eine von einem Server bereitgestellte Datenbank. Im ersten Fall werden alle Daten in einer Datei gespeichert.
  • Nachteil: Die Daten sind also nicht komplett unabhängig von der Klasse der Programmiersprache. Das Format ist proprietär und kann gegebenenfalls von nachfolgenden Programmiersprachen nicht mehr so einfach gelesen werden.
  • Vorteil: Diese kann sehr leicht zwischen Firmen ausgetauscht werden. Der Datenzugriff ist sehr schnell.

Danach werden alle CRUD-Operationen (Create, Read, Update und Delete) ausgeführt:

CREATE

Mit db.store(object) wird ein beliebiges Objekt gespeichert. Dies ist analog zum JPA-Standard, wo em.persist(object) aufgerufen wird. Allerdings muss in letzterem Fall das Domain-Objekt mindestens mit @Entity annotiert oder in XML registriert worden sein.

READ

Es folgt eine einfache Suche mit der einfachsten Abfragesprache Query by Example. Eine Personen-Instanz wird als Muster erstellt und beliebige Felder werden gesetzt. Zurückgegeben werden alle Objekte in der Datenbank, bei denen die Felder passen. found enthält daher das vollständige Objekt, das oben gespeichert wurde.

UPDATE

Dieses found-Objekt wird jetzt intern referenziert und kann daher verändert .setAge(25)und nochmals gespeichert werden. Dann ist es aktualisiert. Im JPA Standard entspricht dieses einem em.merge(object), wobei das Objekt immer attached, also von der Session referenziert (gemerkt) werden muss.

DELETE

db.delete(object) löscht ein Objekt, das dem Objektmanager bekannt sein muss.

db4o bietet drei Abfragesprachen, die alle nicht allzu weit von dem entfernt sind, was Hibernate und JPA in EJB 3.0 bieten:

  Query query=db.query();
  query.constrain(Person.class);
  query.descend("alter").constrain(50).greater();
  ObjectSet result=query.execute();

  var persons = db.Query<Person>( s => s.Age > 50 );

  IList<Person> persons = db.Query<Person>( delegate(Person person){
    return person.Age > 50;
  });

  List<Person> personen = db.query(new Predicate<Person>() {
    public boolean match(Person person) {
      return person.getAge() > 50;
    }
  });

  List personen = db.query(new Predicate() {
    public boolean match(Object object) {
      Person person = (Person)object;
      return person.getAge() > 50;
    }
  });

  ObjectSet personen = db.query(new PersonFilter());

  public static class PersonFilter extends Predicate {
    public boolean match(Object object) {
      Person person = (Person)object;
      return person.getAge() > 50;
    }
  }

Mit dem Öffnen des Containers aus obigem Beispiel wird eine Transaktion erstellt. Diese kann jederzeit mit db.commit() oder db.rollback() auf die Datenbank geschrieben oder verworfen werden. db4o garantiert dabei ein ACID-Verhalten. Alles innerhalb einer Transaktion entspricht den ACID-Anforderungen. Intern werden dabei alle Zugriffe auf die Datenbank innerhalb der Transaktion serialisiert. Dies hat starke Konsequenzen für das Datenbanksystem:

• Durch das proprietäre Datenformat ist der Zugriff für einen Thread zwar meistens schneller als andere Kombinationen aus relationaler Datenbank und objektrelationalem Mapping.
• Dennoch skaliert ein „multithreaded“ Zugriff bei db4o noch nicht, wie er beispielsweise für den Bau von großen Web-Portalen nötig ist.

Erfahrungen zufolge sind normalerweise bis zu einem Dutzend Zugriffe pro Sekunde realisierbar, was für viele Anwendungsfälle ausreichen kann. db4o arbeitet jedoch wegen der obigen Punkte an einer Serverversion, die auch bei nebenläufigen Zugriffen skaliert.

db4o bietet mehrere Arbeitsmodi an:

1. Embedded Mode: Es wird im Anwendungscode ein Objektcontainer geöffnet, wie in obigem Beispiel gezeigt. Basis ist hier ein dateibasierter Zugriff.
2. Client / Server Mode: db4o kann als Server gestartet werden und dadurch von Clients Anfragen entgegennehmen.

Beispiel für den Server:

ObjectServer server = Db4oClientServer.openServer("c:/liveserver.db", 8732);
server.grantAccess("user1", "password");
server.grantAccess("user2", "password");

Hier wird ein Thread geöffnet, der auf Clientanfragen auf dem Port 8732 wartet. Der Server selbst kann über Monitore warten und beispielsweise Statusausgaben machen. Zugriffsrechte können nicht direkt von außen mittels eines Tools verwaltet werden. Entweder werden diese im Code angelegt oder per Konsole etc. eingelesen.

Ein Client könnte initial so eingerichtet werden:

aClient = Db4oClientServer.openClient("196.42.103.142", 8732, "user2", "password");

Mittels eines sogenannten „Out-Of-Band Signalling“-Kommunikationsprotokolls können dem Server beliebige Objekte gesendet werden, mit denen ein Server administriert werden kann. Beispielsweise kann die Aufforderung zum Defragmentieren der Datei übermittelt werden.

Mittels weniger Zeilen können beliebig viele Server repliziert (geclustert) werden. Dies geschieht mit dem db4o-dRS-Modul.

Die Objekte bekommen dazu eine eindeutige UUID. Dadurch können einzelne Objekte oder die gesamte Datenbank uni- oder bidirektional verteilt werden, d. h., jedes neue Objekt wird an alle anderen Datenbanken gesendet. Dies erlaubt es große und redundante Architekturen aufzusetzen.

Sehr interessant ist ebenfalls die Option, eine db4o-Datenbank in relationale Datenbanken zu replizieren. Dies bedeutet eine Brücke / Verbindung zwischen beiden Welten, die oft als getrennt angesehen werden. db4o verwendet dazu Hibernate. Nach der Konfiguration der dRS-Bridge können ebenfalls einzelne Objekte oder ganze Datenbanken per Trigger wahlweise in eine oder beide Richtungen transferiert werden. In vielen Fällen können in der Industrie so die Vorteile beider Welten gut ausgenutzt werden.

Bei db4o gibt es drei Modi für das Laden von Objekten:

IMMEDIATE

Hier werden bei einer Abfrage alle gesuchten Objekte unmittelbar ermittelt. Bei großen Ergebnismengen kann dies viel Zeit und Arbeitsspeicher in Anspruch nehmen.

LAZY

Hier wird sofort ein ObjectSet zurückgeliefert, jedoch ist noch kein Objekt ermittelt worden. Ein Thread sucht alle weiteren Ergebnisse. Dieses Verhalten ist ideal, wenn die ersten Ergebnisse schnell angezeigt werden sollen. Bei diesem Lademodus muss beachtet werden, dass die Abfrage nicht zu einem definierten Zeitpunkt ausgewertet wird. Hierdurch kann es zu Nebeneffekten kommen, wenn zwischen dem Absetzen und dem vollständigen Auswerten der Anfrage Änderungen am Datenbestand vorgenommen werden.

SNAPSHOT

In diesem Zwischenmodus wird die Auswertung aller indizierten Bestandteile der Abfrage zu einem definierten Zeitpunkt vorgenommen. Anschließend wird der Zustand der möglichen Ergebnismenge in einem Snapshot aufgezeichnet. Die weitere Verarbeitung der nichtindizierten Abfragebestandteile findet in einem nebenläufigen Thread statt. Hierdurch werden die Vorteile der verzögerter Auswertung unter Vermeidung ihrer Nebeneffekte bereitgestellt. Für den erzeugten Snapshot wird jedoch Arbeitsspeicher verwendet, der erst mit Freigabe des ObjectSet freigegeben werden kann.

Objekte bilden normalerweise tiefe Referenzstrukturen. In db4o kann beim Laden von Objekten angegeben werden, bis zu welcher Tiefe referenzierte Objekte implizit mit dem Objekt geladen werden sollen. Zusätzlich besteht die Möglichkeit, diese referenzierten Objekte explizit zu einem späteren Zeitpunkt zu aktivieren. Nähere Informationen zu Aktivierung, Deaktivierung, Abfrage und Aktualisierung referenzierter Objekte können in der db4o-Referenz gefunden werden.

Bei db4o gibt es interne und externe Rückruffunktionen (callbacks). Diese ähneln in ihrer Bedeutung den Datenbanktriggern anderer Datenbanken. Rückrufmechanismen gibt es in vielen Produkten zur Datenbankanbindung. Sie sind ein mächtiges Werkzeug um beispielsweise Überprüfungen durchzuführen, Standardwerte zu setzen oder Sicherheitsaspekte zu berücksichtigen.

• Jim Paterson, Stefan Edlich, Henrik Hörning, Reidar Hörning: The Definitive Guide to db4o Apress Inc., Berkeley CA 2006, ISBN 978-1-59059-656-2.
• Patrick Römer, Larysa Visengeriyeva: db4o. schnell + kompakt. Entwickler.press, Frankfurt 2006, ISBN 978-3-939084-03-7.
• William Cook, Carl Rosenberger: Native Queries for Persistent Objects. In Dr. Dobb’s Journal. Februar 2006 (online; englisch; 132 kB).
• William Cook, Siddhartha Rai: Safe Query Objects. In Proceedings of the International Conference on Software Engineering (ICSE). 2005. S. 97–106 (online; englisch; PDF; 143 kB).

• Offizielle Webpräsenz (englisch)
• db4o-Zusammenfassung
• Kurze Einführung in db4o in Java – von Ina Brenner, der Autorin eines db4o-Buchs
• db4o im Datenbank online Lexikon

1. lytico: db4o (database for objects). 3. Januar 2018, abgerufen am 14. Februar 2018.
2. Alexander Neumann: db4objects verkauft sein Datenbankengeschäft an Versant. In: Heise Newsticker. Heise Verlag, abgerufen am 17. Dezember 2008 (deutsch).
3. Actian Corporation Completes Acquisition of Versant. Abgerufen am 15. Februar 2018 (englisch).