Wednesday, July 26, 2006

db4o + ASP.NET = ... s'alright.

I recently just finished up a couple of web application projects were I used Gentle.NET and db4o. Since I haven't blogged for awhile, I guess these topics will make good cannon fodder, right?

There are two immediate down-sides to using db4o: setting it up, and the GPL license. Since I was doing a web app the license didn't matter too much since its GPL 2, although if they upgrade to GPL 3 I'd have to start migrating some of these sites away. Fortunately most of them are "one-shots" -- I won't have to touch them again, nor will any one else, once deployed.

Setting it up is a one-time thing per project, but doing it is kind of a pain in the ass--you have to wander around your application, look for a good entry-point / exit point to setup the database and configurate it (configuration TO THE MAX ! ! !).

After that, though, db4o is just kind of seamless -- you just... use it. Of course, that's not without its few, niggling problems, like everything being an impilict transaction. This means that there's no way to start a "seperate" transaction. The codebase using db4o is littered with the following two lines of code, no variation:

AppUtility.Database.Set(object)

AppUtility.Database.Commit()

...

Everywhere.

It is really, really annoying. Since transactions are impicit this is absolutely necessary to avoid data-loss; and, of course, when I really *NEED* to use a transaction, I need to make sure everything's been committed to the database first, beforehand, so I don't rollback a ton of objects by mistake.

But, so far its been pretty unsurprising, which I guess is what you'd want from a database like this. It works, and that's all there is to it.

technorati tags:, ,

Blogged with Flock

2 comments:

Timothy Parez said...

Could you post some example code on how to set it up in the application ? I assume you need to have a single instance for your entire application?

Bet's On said...

There's not much code to it; just a single static member that persists through the entire application lifecycle.

I put it in a helper class called 'app-helper'; when you first access the member, it checks to make sure the database has been set up, and if it hasn't, sets up the db then returns an instance of the database container object.

I haven't used db4o for awhile (mostly due to interoping with traditional databases) so I can't recall anything off the top of the head other than: db4o does _not_ release references to objects.

You'll need to use its built-in method to do that; db4o doesn't check to see if its the only thing holding a reference to an object so it will hold the reference and consume memory like a mofo till the app slows to a crawl or crashes.

Doesn't work with shared hosting either.

That's about all you need to know.