db4o - A Q&A with Refcard Co-Author Eric Falsken

In coordination with the recently published db4o Refcard, DZone had the opportunity to chat with its co-author, Eric Falsken, a technical evangelist on the db4o team. He has been a staunch supporter of Microsoft .NET (much to the chagrin of his open source-loving co-workers) and enjoys coming up with new ideas for elegantly usable software, and mentoring fellow students of software.

DZone - What is db4o?
Eric Falsken - db4o is an open-source object oriented database. It runs natively, entirely within .NET.

DZone - Is db4o primarily used as an in-memory database? Or is it used to maintain state after the application is shut down or user logs off? Can you elaborate?
Eric - Not in-memory. It's for persisting object state. A typical use-case is when someone outgrows direct serialization: the data model takes too much time to de/serialize, too much to fit in memory, or if they need the model to be queryable. These users typically are strongly resistant to a more traditional relational database because either they don't have the resources to run a full DB server (resource constrained devices), their object model is too fluid or the schema is constantly evolving, or they don't have time/desire to code an entire persistence layer....db4o IS your persistence layer with no schema to pre-define and no DB server to manage.

DZone - What are the primary uses of db4o? An application database? A cache? Something other?
Eric - I've seen db4o used in everything from high-speed trains and medical imaging devices to web-based search engines and facebook plug-ins. Although it isn't perfect for every app, anyone who has occational need for simple, easy persistence shoud have db4o in their toolbelt.

DZone - The RefCard points out that once a database file is open, it cannot be accessed by another application. How about by another user? For instance, if db4o is running on the server in a web application? Or would each user have their own database file?
Eric - The reason for this is that db4o is meant to be as thin as possible. Multi-user or multi-session databases almost always tend to be either bulky or slow, especially when you want to cross-optimize AND provide ACID transactions. Access and SQL server are perfect examples of what happens when you try to do both. In the web server scenario you mention, a common solution is to broker all of the requests to a single persistent connection to the db opened and managed in the application context instead of per-request, or to use an in-process client/server model (mentioned in the refcard).

DZone - The RefCard talks about SODA queries? What are they?
Eric - SODA queries were a standard created a number of years ago as a way to express a data query using object-oriented syntax. It's not overly complicated, but (just as with LINQ) we did not have room in the refcard to include a complete reference for the syntax. Especially when db4o provides something as elegant as Native Queries where you don't have to learn any query language at all.

DZone - If I need optimal performance, which query alternative performs best? Query by Example, Native Queries, LINQ, or SODA?
Eric - If you use Db4oTool to instrument your queries, there is no difference between NQ and the more-native SODA or LINQ queries. Db4oTool looks at your native C# or VB code and converts it to the equivalent SODA expression, which the db4o query engine handles directly. LINQ is similar enough to SODA that only a small translation must occour.

DZone - Object activation appears to be an easy way to optimize object load time from the database. Is there a way to automate late activation when the object is referenced? Or is manual activation the only choice?
Eric - Great improvements have been made with something we call Transparent Activation. Using the same Db4oTool, all of your persistent classes can be instrumented to dynamically load/activate child objects when first accessed. It's quite easy to use, but much more difficult to optimize. Transparent Activation is still in development, and is not yet ready for production use, so was not discussed in the refcard. Because db4o is an Open Source project, we encourage anyone interested to try it out on their project and to let us know how it works for them.

DZone - Are there important traps to avoid when using db4o? Can you provide a simple scenario?
Eric - The simplest traps were mentioned in the refcard: Open your db when your app starts up, and close it when you shut down. (avoids broken object references and duplicates getting stored in your db) Don't forget to <code>store()</code> your child objects, or else set cascading updates, or else you'll be surprised when your changes are saved to the db. (updated object values will still be in memory in your objects, but not next time you reload the data) Don't forget that the .NET runtime will not garbage collect objects with direct references from objects in use. Instead of collections of child objects, maybe consider replacing collections with property getters which return a list of child objects retreived from a query. (avoids what will look like a memory leak) And lastly, make sure you are familiar with and use object-oriented design principles. Many years of working with relational data persistence (blindly shoving any and all data into a database) has caused us to become used to relational data access patterns.

DZone - Are there any recommended tools you'd recommend using with db4o?
Eric - The only tools you need are a good IDE and a debugger. You may also want to look into profiling tools if you are targeting a resource-constrained device.

DZone - Is there a version of db4o available for Java?
Eric - Absolutely! The Java version has all the same great features and functionality as the .NET version, and is completely interoperable. Both environments can even use the same database!

DZone - What's on the future enhancements lists for db4o? What features are coming soon?
Eric - I hear the development team is just wrapping up IUpdatable support which will nicely compliment IQueryable for 2-way LINQ and support for ADO.NET Data Services and Entity Framework. All progress tracking and future planning happens on the project tracker (http://tracker.db4o.com) which anyone is free to browse and participate in. Vote for your most desired features!


Thank you for the time, Eric.

Kirk an industry analyst at Burton Group. For 15 years, I worked in the trenches on real software projects. I believe software development is an amazing profession. I take a keen interest in design, architecture, application development platforms, agile development, and the IT industry in general, especially as it relates to software development. I also enjoy experimenting with new technology, whether it be the the cool new framework or tethering my smartphone to my Mac via Bluetooth to get an internet connection. Kirk is a DZone Zone Leader and has posted 55 posts at DZone. You can read more from them at their website.