Objectives
The main objective of the "Db4o-Out-Of-The-Box Presentation" is to provide db4o User Groups with a standard presentation to introduce a technical audience to db4o (including many code examples). The text below (adapted from our Reference documentation) serves as a template to generate the slides for a presentation (I wanted it to keep it editable so the community can easily help enhance the presentation). You can download a Powerpoint presentation based on the contents here:
Db4o_Out-Of_-The-Box_Java.Zip (full Java version, around 90 slides)
Db4o_Out-Of_-The-Box_Java_Medium.Zip (medium Java version, around 60 slides)
Db4o_Out-Of_-The-Box_Java_Minimal.Zip (short Java version, around 30 slides)
Your feedback is welcome! Please send an e-mail to community@db4o.com
Introducing db4o
db4o is the only open source native object database for both Java and .NET, available under a dual licensing model. 20,000 registered community members and more than 1,000,000 downloads make db4o the world's most popular object database. db4o is used by some of the world's most innovative companies, including Ricoh, Boeing, BMW, Bosch, Seagate, and Intel.
db4o is firmly embedded in a large network of open source partner products and projects, to help you integrate db4o easily in your own environment. db4o works with distinguished open source partners such as Eclipse, Mono, Red Hat, Spring Modules, JPOX, Boo and Prevlayer to provide better software to you.
Origins
db4o was created in 2000 by Chief Architect Carl Rosenberger as his first Java application, it later shipped in 2001. Some 100 commercial pilot customers and a loyal user community have endorsed db4o from its earliest days, and proved it ready for mission-critical applications prior to its commercial launch in 2004.
At present the project is mature enough to feature a Project Steering Committee, state-of-the-art resources to make it easier for developers to contribute, monitor and learn about the project and a huge supporting community.
Key features
Overview
- Objects are stored as they are (no conversion or mapping)
- No changes to classes to make them storable
- Store objects of any complexity natively with only one line of code
- Automatic management of the database schema
- Seamless Java (or .NET) language binding
- Installation by adding a single 500Kb library file (Java jar or .NET DLL)
Deployment
- Easy deployment
- Simple deployment as a library/jar
- No separate database installation
- Zero administration
- Hot backup
- Defragment
- Application-managed authorization
- Automatic object schema versioning
- Database upgrades objects automatically to match current class definitions
Reliability
- Full ACID transaction model (Atomic, Consistent, Isolated, Durable)
- Data transaction journaling ensures zero data loss in case of system failure
- Automatic data recovery after system failure
- db4o core is thread-safe for simultaneous operations
Performance
- 100% native implementation ensures fastest performance
- Running the db4o engine in-process eliminates needless data transportation
- Elimination of O/R Mapping logic allows db4o to run up to 44 times faster
- Smart object caching gives huge boosts in performance when re-querying the same data
- Integration with native garbage collection saves memory and reduces footprint when needed
Security
- Pluggable encryption algorithm (xTEA)
- Encrypted and password-protected database files
- Network access control list (username, password)
Basic Usage
The ObjectContainer
db4o gives you a simple and straightforward interface to object persistence - the ObjectContainer. In .NET versions a conventional name IObjectContainer is used.
ObjectContainer is your db4o database.
filename is the path to the file, in which you want to store your objects. Normally you should open an ObjectContainer when the application starts and close it, when the session is finished to persist the changes to a physical storage location.
ObjectContainer interface gives you all the basic functionality to work with persistent objects. Normally you can save a new or updated object of any class using ObjectContainer#set(object) (see Saving Objects)
Deletion is done with the following method:
Through ObjectContainer#get() and ObjectContainer#query() you get access to objects retrieval functionality (see Querying Objects). The characteristic features of an ObjectContainer are:
- An ObjectContainer can either be a database in a single-user mode or a client connection to a db4o server.
- Every ObjectContainer owns one transaction. All work is transactional. When you open an ObjectContainer, you are in a transaction, when you
commit() or rollback(), the next transaction is started immediately.
- Every ObjectContainer maintains it's own references to stored and instantiated objects. In doing so, it manages object identities, and is able to achieve a high level of performance.
- ObjectContainers are intended to be kept open as long as you work against them. When you close an ObjectContainer, all database references to objects in RAM will be discarded.
Basically ObjectContainer supplies functionality, which is enough for the most common usage of db4o database. Additional features are provided by an interface extending ObjectContainer - ExtObjectContainer.
The idea of splitting basic and advanced functionality between 2 interfaces is:
- Keep the root package/namespace very small and well readable.
- Separate vital and optional functionality.
- Make it easy for other products to implement the basic db4o interface.
- Show an example of how a lightweight version of db4o could look.
Every ObjectContainer object is also an ExtObjectContainer. You can cast it to ExtObjectContainer or you can use #ext() method to get to the advanced features.
Saving objects
As the ObjectContainer is your database we also use it for storing objects. We call this a "set" operation. The good thing about a set operation is that you can use it to store objects of arbitrary complexity (you can set the update depth in db4o).
We show an example now where some Pilot objects are saved. The object domain for the examples is based on the PolePosition benchmark for Java databases which includes Pilots, Cars, Circuits, etc.
Note that we're obtaining an ObjectContainer by opening the database in Client/Server mode instead of local mode (as showed before) but the operations that you can do on the ObjectContainer are the same (this homogeneity is very useful if you need to switch your app between local or client/server mode later).