db4o Developer Community

Hi,

I'm trying to use db4o (5.0) for an ASP.NET 2.0 website, and I'm having trouble understanding the results
I get when restarting my server.

I use a single ObjectContainer to manage all the objects, and the container is opened once,
and kept for as long as the application runs (i.e. not once per request or once per session).
Comments on this setup are welcome by the way...

When I restart my application container, which is currently the asp.net test server, the objects
inserted during the next run will have a "different identity" somehow.

If I insert 3 objects in my database, first two objects during one run, then restart my webserver and insert another one,
my file contains the following three objects, if viewed in object manager:

-MyNamespace.MyType, App_Code.b3o_rrig
 - + (G) MyNamespace.MyType, App_Code.b3o_rrig (id=561)
 - + (G) MyNamespace.MyType, App_Code.b3o_rrig (id=2332)
-MyNamespace.MyType, App_Code.jf4svw7
 - + (G) MyNamespace.MyType, App_Code.jf4svw7 (id=3075)

No change to the class MyType was made between the test runs.
If I do a SODA query on this database  using Constrain(typeof(MyNameSpace.MyType)), then I will
only get the results inserted during the current run of my application.

Is this the expected behavior? Is this an effect caused by .NET, db4o, or perhaps the visual studio/asp.net test server?
Also, am I correct in thinking that I'd like just *one* root node in object manager, if all my objects are of the same
type, and not one root node per "identity".

Thanks for any pointers, and for a great product

Anders

andersf wrote:

I'm trying to use db4o (5.0) for an ASP.NET 2.0 website, and I'm having trouble understanding the results I get when restarting my server. [...] When I restart my application container, which is currently the asp.net test server, the objects inserted during the next run will have a "different identity" somehow. If I insert 3 objects in my database, first two objects during one run, then restart my webserver and insert another one, my file contains the following three objects, if viewed in object manager: -MyNamespace.MyType, App_Code.b3o_rrig  - + (G) MyNamespace.MyType, App_Code.b3o_rrig (id=561)  - + (G) MyNamespace.MyType, App_Code.b3o_rrig (id=2332) -MyNamespace.MyType, App_Code.jf4svw7  - + (G) MyNamespace.MyType, App_Code.jf4svw7 (id=3075)

Strange. This is not only a different 'identity', but a different class. Where does the class definition for these objects come from? Is it perhaps generated by the ASP server? (I'm a Java guy, never even remotely touched ASP[.NET] so far.)

Best regards,
Patrick

patrick_roemer wrote:

andersf wrote: -MyNamespace.MyType, App_Code.b3o_rrig  - + (G) MyNamespace.MyType, App_Code.b3o_rrig (id=561)  - + (G) MyNamespace.MyType, App_Code.b3o_rrig (id=2332) -MyNamespace.MyType, App_Code.jf4svw7  - + (G) MyNamespace.MyType, App_Code.jf4svw7 (id=3075) Strange. This is not only a different 'identity', but a different class. Where does the class definition for these objects come from? Is it perhaps generated by the ASP server? (I'm a Java guy, never even remotely touched ASP[.NET] so far.)

*gna* Quite obviously I'm not the .NET guy. :( This is not a different class, but a different assembly identity, I guess. Not the slightest idea about this stuff, sorry.

Best regards,
Patrick

I am not sure about understanding the question but

 

While Setting, deleting objects with db4o, you are in an implicit transaction.. Unless you commit it, it wont be written into db. when it closes, then the objects are set to db..

If you want your db affected As soon as you use the method "set" or "delete", you should commit it.

I understood the question now, sorry for the answer before...

 

Like patrick said, I think it is a result of different identity. I experienced the same problem but i couldnt solve it..

 

I'll take a look at google and come back...

I take a look at google but couldnt find a way..

hede m=new hede();

hede n =new hede()

Response.Write(m.GetType().GUID.ToString() & "<br>")

Response.Write(n.GetType().GUID.ToString() & "<br>")

 

First run of this code returned

43a50476-1deb-3c01-953f-7779c4d26d41
43a50476-1deb-3c01-953f-7779c4d26d41

 

and then closed the vs.net and opened the project again..

43a50476-1deb-3c01-953f-7779c4d26d41
43a50476-1deb-3c01-953f-7779c4d26d41

 

the result was the same...

But when I add another field to the hede class, the guid changes, of course..

It sounds like your problem is that you aren't calling commit() after adding your objects to the database. You don't have to call it after every object, but you should definately call it before your request is done processing.

I use a single ObjectContainer to manage all the objects, and the container is opened once, and kept for as long as the application runs (i.e. not once per request or once per session). Comments on this setup are welcome by the way...

This is fine, but be aware that if you call commit() you will also be commiting any other object changes made by any other page request going on at the same time. Sometimes, you just don't care about ACID transactions, and this will be perfectly safe.

Also be aware that if 2 page requests query the DB for the same object, they will both be working with the SAME object in memory. You can run into multi-threading bugs this way, like race conditions, overwriting eachother's changes, interlocks, deadlocks, etc. This isn't necessarily a bad thing if you know about it, and expect it. In fact, running this way gives you the best possible performance (while sacrificing some possible integrity).

A good balance, is to open an objectServer in the application scope, and then to use objectServer.openClient() to get a "client" object container to service each request. This ensures that each request will get it's own object in memory, and any commit() called will be isolated to the changes made only durring that page request. But, since each page request will be getting it's own copy of any DB objects, you loose any performance gains you may have had from object caching. (unless an object is queried from the DB more than once durring the servicing of a single page request)

---

Eric Falsken » db4objects

Eric Falsken wrote:

It sounds like your problem is that you aren't calling commit() after adding your objects to the database. You don't have to call it after every object, but you should definately call it before your request is done processing.

Thanks for your response.

I only have a simple test  page with a form, that on  submit  will add a simple object  of my class to the database.
I call set() and immediately after I call commit(), so that can't be the problem.

The problem appears to be in the way that my IDE and Test server (Visual Web Developer 2005 Express and its
embedded asp.net server) handles assembly names for the new fancy "on the fly" compilation of classes.
All "extra" code (not directly related to any page) is contained in the App_Code directory of the site.
When deployed, this code can be compiled when needed. This means
that the target assembly will be generated at the time of build (I can't find any setting) with a random name. Currently, the
assembly name looks like "App_Code.randomjunk123". This name also changes sometimes, but not always.
When it does, it means trouble for my db4o objects :(

So the fully qualified name of my class is
MyPackage.MyClass, App_Code.randomjunk123, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null

And I suspect this fully qualified name is what is used when I'm, for example, constraining a query by Class?
What I need to do is probably just try to use precompiled assemblies with pre-specified, non-changing names.
I'm going to bug the Redmond people and get back here if I find something useful.

And thanks for the openClient-tips!

Anders

Oh, yes, you are certainly right. db4o does depend on the assembly name as part of the type name. So when you run a second time, the type that you are searching for, is in fact, a different type from the previous itterations. For now, I recommend doing a manual compile in Visual Studio before each test run.

---

Eric Falsken » db4objects

Using a sensible, fixed assembly name does the trick of course! Thanks Eric & others for your help.


I'll briefly describe what happened since I think this will be a fairly common problem:

After some investigations it turns out that you should definitely avoid having classes defined in the ASP.NET 2.0 App_Code-directory if you intend to store them in db4o (or persist them in any other way). This spells bad news for users of Microsofts free IDE Visual Web Developer 2005, since you can't have "sub-projects", like you can in the full version, Visual Studio. In web developer you have to do a manual compile of your persisted classes, and reference that dll. In Studio, you can have a subproject that is built to an assembly with a specified name, which is then referenced.
Apparently you can use the dynamic compilation features if you build your website on the commandline, if you specify the flag -fixednames for the website compilation. This will generate repeatable assembly names.

Regards

Anders

Great job Anders! This issue should be published more prominently in the manual in a "caveats" or "watch out" section. The symptoms of this problem with VS mangling the assembly name are varied and non-intuitive. I've been playing for db4o in a web app for some time in VS 2005, and was getting non-deterministic results when running commands like this from VS's Debug immediate window (running commands as the app is running):

db.Query<Persona>().Count

0

db.Query<User>().Count

1

db.Query<object>().Count

9

db.Query<Persona>().Count

0

db.Query<User>().Count

2

 

Clearly, this led me to pull my hair out. The fix is simple enough, but it took me a couple of hours to find something helpful (this post) in the forums.

Update: I've posted about this problem with some context here:

http://philisoft.com/blog/aspnet-on-the-fly-compilation-and-db4o/

andersf wrote:

Using a sensible, fixed assembly name does the trick of course! Thanks Eric & others for your help. I'll briefly describe what happened since I think this will be a fairly common problem: After some investigations it turns out that you should definitely avoid having classes defined in the ASP.NET 2.0 App_Code-directory if you intend to store them in db4o (or persist them in any other way). This spells bad news for users of Microsofts free IDE Visual Web Developer 2005, since you can't have "sub-projects", like you can in the full version, Visual Studio.

We are just about to release development version 5.3 with class aliases.

They should solve this problem nicely, if you call something like the following:

Db4o.Configure().AddAlias(
  new WildcardAlias(
    "*, ASPAssemblyNameJunk123VeryFirstSession",
    "*, ASPAssemblyNameJunk456CurrentSession"));

 

I am a little confused as to how to put this into practice.  Do I have to alias every permutation of assembly names as I modify code in the App_Code directory?  Unless I'm confused, this doesn't seem to scale too well when using many classes with frequent modifications to the code.