great things do come in small packages! weighing in at 420kb, this OODBMS now has built-in support for replication.
read the complete article
here.
to use db4o effectively in ASP.NET, place all your business classes in a separate class library project and then refer to that project in your ASP.NET project. avoid putting class definitions in the App_Code folder of your project since this will be compiled on the fly and given a different namespace every time it is recompiled. this means that instances of the class Foo, which was compiled yesterday, will have a different namespace from the the instances of the class Foo that is compiled today. db4o will treat instances of class Foo that was stored yesterday and today as belonging to different types since their namespaces are different.
it is important to keep the db4o client open during a particular session and just close the client when that session ends. the best way to do this is to use an HttpModule as illustrated by the class below.
internal class Db4oHttpModule : IHttpModule
{
const string KEY_DB4O = "db4o"; // appSettings key
const string KEY_CLIENT = "db4oClient";
private static ObjectServer server = null;
internal static ObjectContainer Client
{
get
{
HttpContext context = HttpContext.Current;
ObjectContainer client = context.Items[KEY_CLIENT] as ObjectContainer;
if (client == null)
{
client = Server.OpenClient();
context.Items[KEY_CLIENT] = client;
}
return client;
}
}
private static ObjectServer Server
{
get
{
if (server == null)
{
string yapFilePath = HttpContext.Current.Server.MapPath(ConfigurationManager.AppSettings[KEY_DB4O]);
server = Db4o.OpenServer(yapFilePath,0);
}
return server;
}
}
private void OnApplicationEndRequest(object sender, EventArgs e)
{
HttpApplication application = (HttpApplication)sender;
HttpContext context = application.Context;
ObjectContainer client = context.Items[KEY_CLIENT] as ObjectContainer;
if (client != null)
{
client.Close();
}
client = null;
context.Items[KEY_CLIENT] = null;
}
public void Init(HttpApplication application)
{
application.EndRequest += new EventHandler(OnApplicationEndRequest);
}
public void Dispose()
{
if (server != null)
{
server.Close();
}
server = null;
}
}
after going thru many several programming languages and databases in my
20+ years of working with computers, seldom do i find myself excited
with the plethora of tools that have been coming out of late,
WinFX nothwithstanding. maybe i'm just getting a little bit
older or have i just become jaded with all the hype and promises
which turn out to be too good to be true.
the first time i read about db4o i never really bothered with it since
it was more of a java thing back then - not anymore. it has
become a mature cross platform OODBMS for java or .NET/ MONO, linux or
windows. db4o is actually being positioned as an
embedded/mobile database but more and more people are actually using it
for desktop and ASP.NET applications. include me on that list.
what i really like about using db4o as a backing store is it frees you
from making compromises with your business models, which normally
happens when you're designing apps with an sql database as backing
store. this side effect is like a breath of fresh air to harried
developers like me.
the db4objects June newsletter claims that version 5.4 which is currently in development, sports a new B-Tree index architecture, and object marshaller. As a result:
- You can store up to 250 million objects with a constant RAM
consumption of less than 40 MB and a constant insert performance of
8,000 objects per second -- measured on a slow hard disc! Previously,
Version 5.2 had shown drastic insert performance drops and RAM
consumption over 300 MB once one attempted to commit more than 10
million objects, which consequently marked the boundaries for the
feasible scalability of version 5.2.
- 100,000 objects have
been stored successfully with a constant RAM consumption of less than
2MB, a scenario typical for handhelds, making db4o one of the most
powerful and best-performing persistence solutions on resource
constrained devices.
- Measured with 10 million objects,
commit performance of class indexes is now even 11x faster than with
version 5.2, running at 400 milliseconds instead of 4.5 seconds on a
slow hard disc!
these figures are awesome!