Getting Started With db4o

on

Recently I was starting up a new project and got to the point where I needed to persist some of my objects to a database.  Instead of doing what I normally do, NHibernate and SQL Server, I decided to try something new.  A colleague of mine told me about db4o a few weeks ago so I decided to take it for a spin.

Just in case you don’t already know, an object-oriented database stores your objects directly in the database without having to map it into a relational structure.  No object-relational impedance mismatch that we usually get with relational databases.

db4o uses a custom file format to store your objects.  It supports both local in-process access as well as remote access over TCP/IP.   It supports all your standard CRUD stuff, has transactions, and extensive query support through a custom query API and LINQ.

Get db4o

Head on over to http://www.db4o.com and download db4o.  In addition to the db4o runtime, you can also install ObjectManager Enterprise which is a Visual Studio plugin for browsing objects in a db4o database.  OME is an object browser for a db4o database. 

The SDK and runtime are in the bin\net-3.5 directory of the installation location.  Db4objects.Db4o.dll, Db4objects.db4o.CS.dll, and Db4objects.Linq.dll are the core libraries.  There are other libraries in the same folder that add additional features.

Host db4o

There are two ways to host db4o: embedded single client and client/server.  The client/server mode can be configured for local or remote connections.

Embedded Single-Client Mode

Embedded single client mode is great if you have a desktop app that needs to persist some data to the local file system.  It allows only a single connection to the database.  Other connections will get an exception when opening the database file.  The embedded database API is in the Db4objects.Db4o.dll library

To open or create a new embedded database, call Db4oEmbedded.OpenFile, passing in a configuration object and the path to the database file.  The returned object will be of type IObjectContainer and is the primary interface for interacting with your database.

Client/Server Mode

When you need more than a single connection to the database, as typical in web applications, you need to use the client/server mode. Whether you need remote, out of process connections or local inprocess connections will determine how the client/server mode is configured. For in process connections only, configure the server to run with a port number of zero(0). To allow remote connections, give the server a port number greater than zero. Remote connections use TCP/IP. The client/server API is in the Db4objects.db4o.dll library.

To start the database server, call Db4oClientServer.OpenServer, passing in a configuration object, the path to the database file, and a port number.  A port number greater than zero will allow TCP/IP connections to db4o. For servers that will allow remote connections, you need to grant access to a username and specify a password for the username

How you open a client is determined by if you are connecting to a local or a remote server. For local servers, you call the OpenClient method of the IObjectServer. For remote servers, you call Db4oClientServer.OpenClient, passing in a configuration, host name, port, username, and password

The CRUD

db4o handles the basic CRUD operations.

There are a few gotchas when doing updates/deletes with object graphs.  You must tell db4o how to cascade when you open the connection.  This is accomplished through the configuration object that is passed as the first parameter to the OpenClient/OpenServer methods.

Querying

db4o has extensive querying support including query-by-example (QBE), native queries, SODA, and LINQ. LINQ is the preferred way to query in .net applications and should be used for the majoriy of your queries. An example of a LINQ query was provided in the previous example. SODA queries are db4o's low level API. Native queries use the native language, C# in this case, to query the object store. QBE is where you give db4o a prototype of what you want and it will find everything matching it

SODA Queries

Query-by-Example

Native Queries

Transactions

Similar to other database systems, db4o provides a transaction mechanism. Opening a transaction is implicit when you open a connection to the database and implicitly committed when you close it. During the lifespan of an open connection, you can commit any changed state to the database before closing the connection. You can also perform a rollback to reset the state of an open connection to the last commit point or to the opening state of the connection if you have not done a commit. 

Rolling back the database poses a problem though.  When doing a rollback, we rollback the database but not any of our live objects.  The solution to this is found in the Ext library in the form of the Refresh method.

Wrapping Up

There is a lot more to db4o than I talk about here. Read through the documentation that comes with it and then head over to the developer forums at the db4o site to get answers for any outstanding questions you may have.

Monitoring MSMQ

2
on

I have been looking for a solution to monitor MSMQ queues at work.  Luckily, Windows ships with 2 tools that we can utilize to help us out: Performance Monitor and Event Log.

Alerts are defined in perfmon to monitor the number of messages in our queues.  When the limit is reached, a trigger is fired.  In our installation, we have the trigger set to write a message to the event log using a specific event id.  The operations/infrastructure team responsible for keeping the systems running use a commercial product to watch the event logs for our event id.

How do you monitor MSMQ?

What I’ve been up to

0
on

It’s been awhile since I last posted anything.  This post is just to let the world know that I am still alive and what I have been working on these past few months.

At the office

At work, its the same old boring stuff of maintaining a legacy asp.net web forms app from hell.  I say from hell because it has a hand rolled DAL, over 20 projects, table based markup, asp.net ajax toolkit, …well you get the point.  Our marching orders are to keep it up and running while adding features to support our ever changing business.

Early on we did some broad refactorings (code reformatting, removing singletons, cleaning up cross project dependencies) with marginal success.  Here lately the work has been on improving performance.  Part of that has been me analyzing performance counters and log files from our production systems.  Hopefully I will get the urge to write about the specifics as I believe it is valuable information that I will need again in the future.

In the next few weeks I hope to spend less time on the legacy system and more time working on the strategic enterprise architecture stuff.  Our discussions to date have been about how SOA, EDA, messaging, etc can help the software stay agile and change at the pace of the business.  More on this at a later date as well.

At the house

At home I am focusing on a side project that is built using  ASP.NET MVC, NServiceBus, and db40. 

Let me tell you, db4o is really cool.  There is very little code to get it up and running, especially when combined with a framework like NCommon,  And the whole NoSQL stuff is just great.  Head on over to www.db4o.com and have a look.

This weekend I have been writing a subscription storage and saga persister for nservicebus using db4o which I plan to contribute back to the project.