dbobjects Inc. has released db4o 4.5, open source object db

Discussions

News: dbobjects Inc. has released db4o 4.5, open source object db

  1. dbobjects Inc. has released db4o 4.5, an open source object database engine. The new version comes with object replication for distributed databases. It also has improvements in the reflection mechanisms.

    With the new replication mechanism, the objects themselves can carry the business rules for resolving synchronization conflicts in the data layer.

    db4o's pluggable reflector interface allows Java developers to write their own reflectors. Version 4.5 advances this functionality with a new generic reflector further enabling tuning for distributed systems, cross-platform support, and enhanced encryption capabilities.

    With the generic reflector, developers can now run a db4o server without having to deploy application classes. They can also easily access objects and values where classes or fields are no longer available as source code.

    One implementation of this is the new ObjectManager, which allows developers to "look" into databases and monitor what's happening in real-time while they write applications. It can also be used by third parties to browse a database file, and/or to build ad-hoc queries for instances of a class. This helps ease the transition to OOP-thinking for developers new to OOP or ODBMS or both.
  2. Interesting. This seems perfect for applications with little data such as much desktop apps and small web sites. Or does it target other apps as well?

    I did not read all of the documents, but I did not see something that explains the architecture and technical side of the implementation. This is IMHO invaluable to get attention in the open source arena. Furthermore I did not read any statement regarding how big a db40 database can get without affecting performance.

    Also I am wondering, is there a way to export data? Xml?
  3. Interesting. This seems perfect for applications with little data such as much desktop apps and small web sites. Or does it target other apps as well?
    The success stories on the website may get you an idea. We see most advantages for using db4o when
    - performance is critical (benchmark results)
    - complex class hierarchies are used
    - ressources are constrained
    ...but any other application will also benefit from the ease of a system that simply analyzes the classes of your application and stores objects as they are, without a single line of mapping code or schema description.
    I did not read all of the documents, but I did not see something that explains the architecture and technical side of the implementation. This is IMHO invaluable to get attention in the open source arena.
    db4objects Inc. owns all IP of the project and employs developers. Accordingly continous development of the project and professional support are guaranteed without voluntary contributions by the community.
    Furthermore I did not read any statement regarding how big a db4o database can get without affecting performance.
    The maximum database file size is 254GB. By only using one single indirection of an ID or reference to an actual object in the database file, navigational performance will remain constant, no matter what size the database file will be. Tree indexes are supplied for queries against fields. Feel free to download this benchmark and raise the numbers of objects stored to what you need for your application.
    Also I am wondering, is there a way to export data? Xml?
    Sure. You can use any technology that can write Java objects to XML, XStream for instance.
    --
    Carl Rosenberger
    Chief Software Architect
    db4ojects Inc.
    http://www.db4o.com
  4. Tried it, but had problems with corruption (i think it was due to the ObjectManager, not db4o itself)

    Also, the network backend seems very simplistic and doesn't scale well (one thread per client!) Good for prototyping of applications, though. Perhaps also nice as a embedded solution, but I wouldn't use it for large-scale client/server deployments. My biggest consern is that db4o only supports optimistic locking.

    Also, db4o only supports SODA (which IMHO is hell on earth to use for complex queries), not a proper query language, which makes this useless for applications where ad-hoc reporting is necessary.

    I am a big believer in object databases, but there are few, if any, really good ones out there. Matisse is very nice, but .NET/Java support is not quite there yet. Objectivity rocks, but the price tag is horrible.
  5. Tried it, but had problems with corruption (i think it was due to the ObjectManager, not db4o itself)
    On our downloadcenter page we supply three different levels of maturity: stable, production (recommended), development. Indeed our new generic reflection implementation was broken in our first ObjectManager development build. Please test with the recommended production builds if you want to test for stability.
    Also, the network backend seems very simplistic and doesn't scale well (one thread per client!)
    Indeed the server uses one thread per client. The recommended setup for large-scale deployments is to use multiple servers on multiple machines and to use the replication functionality to synchronize objects.
    My biggest consern is that db4o only supports optimistic locking.
    This is true on object level but you can use semaphores to implement your own pessimistic behaviour.
    Also, db4o only supports SODA (which IMHO is hell on earth to use for complex queries), not a proper query language, which makes this useless for applications where ad-hoc reporting is necessary.
    In
    this posting to our newsgroup I try to point the advantages of S.O.D.A. for constructing queries in modules, constraint by constraint. We know that reporting is an important issue for our users and that there are still surprisingly few good tools around that can report against plain-old-Java-objects. Accordingly we are already working on SQL access to our engine for reporting purposes.
    I am a big believer in object databases, but there are few, if any, really good ones out there.
    Please stay tuned on us, I am sure we will get there, also for your requirements.
    --
    Carl Rosenberger
    Chief Software Architect
    db4objects Inc.
    http://www.db4o.com
  6. In [this posting to our newsgroup] I try to point the advantages of S.O.D.A. for constructing queries in modules, constraint by constraint.

    My eyes got sour half way through the posting. I really, really, dislike SODA. Sorry.
    [...] Accordingly we are already working on SQL access to our engine for reporting purposes.

    Interesting. Will this be true SQL, or will it be some proprietary OQL language? When will this feature be available?
    My biggest consern is that db4o only supports optimistic locking.
    This is true on object level but you can use semaphores to implement your own pessimistic behaviour.

    I think 9 out of 10 database systems provide automatic, pessimistic locking. Pushing this responsibility to the programmer is not an option, IMO. But then again, opinions vary.
    Please stay tuned on us, I am sure we will get there, also for your requirements.

    Sounds good :-)
  7. My eyes got sour half way through the posting. I really, really, dislike SODA. Sorry.
    The essence of my posting is: Using modules to create queries allows code reuse to achieve your own level of abstraction. You end up with this:

    ObjectSet objectSet = Account.queryFor(
      objectContainer,
      new int[] {
        Account.PERSONNEL,
        Account.RECRUITING,
        Account.LEGAL,
        Account.SALES,
        Account.FACILITIES
      },
      Account.POSITIVE,
      "hantheman"
    );

    instead of this:

    SELECT * FROM Account, Person WHERE
      ((Account.number >= 10000 AND
       Account.number <= 10999)
       OR
      (Account.number >= 30000 AND
       Account.number <= 30999)
      OR
      (Account.number >= 33000 AND
       Account.number <= 33999)
      OR
      (Account.number >= 44000 AND
       Account.number <= 44999)
      OR
      (Account.number >= 56000 AND
       Account.number <= 56999))
      AND Account.balance > 0
      AND Account.manager = Person.id
      AND Person.name = 'hantheman';

    (additional code to wrap parameters into JDBC statements omitted for readability)

    The more complex your queries get, the more it will help if you can construct queries with individual modules and methods. You are not forced to use plain S.O.D.A. if you don't like it. Feel free to build your own abstraction layer on top, that's exactly what it is for.


    [planned SQL support]
    Interesting. Will this be true SQL, or will it be some proprietary OQL language?
    It has to be true SQL since we want to enable the use of SQL reporting tools.
    When will this feature be available?
    A first release is planned in three months.
    I think 9 out of 10 database systems provide automatic, pessimistic locking. Pushing this responsibility to the programmer is not an option, IMO. But then again, opinions vary.
    From my experience with relational databases a large percentage of applications (9 out of 10 ?) with high concurrency has one of the following problems:
    (1) It does not understand locking issues at all and simply does not care about doing things wrong and producing slight inconsistencies every now and then.
    (2) Deadlocks are always threatening the system to come to a halt.
    (3) Optimistic strategies fail frequently and reissuing the business logic imposes a very high workload on the system.

    The problem with object databases and automatic pessimistic locking: Because the database system is very tightly integrated with your objects you can't get away with (1). The system will really set all locks and obey all of them. You are bound to either fight with (2) or (3). Don't blame it on the database system.

    --
    Carl Rosenberger
    Chief Software Architect
    db4objects Inc.
    http://www.db4o.com
  8. The essence of my posting is: Using modules to create queries allows code reuse to achieve your own level of abstraction. You end up with this:

    Pretty strange example. I almost never select ranges and if I do, I use BETWEEN which is much less verbose. I'd rather see real-world examples showing the SODA-way of doing projection, UNIONS, LEFT JOINS and SUB-SELECTs...
    From my experience with relational databases a large percentage of applications (9 out of 10 ?) with high concurrency has one of the following problems:(1) It does not understand locking issues at all and simply does not care about doing things wrong and producing slight inconsistencies every now and then.(2) Deadlocks are always threatening the system to come to a halt.(3) Optimistic strategies fail frequently and reissuing the business logic imposes a very high workload on the system.The problem with object databases and automatic pessimistic locking: Because the database system is very tightly integrated with your objects you can't get away with (1). The system will really set all locks and obey all of them. You are bound to either fight with (2) or (3). Don't blame it on the database system.--Carl

    We definitely have different experiences, then. I've worked in the finance sector, now telco, where high-contention data models are somewhat frequent (i.e. bye/sell stocks where individual stocks are VERY popular resources) If we were to use optimistic locking on these, *most transactions would abort*. We even experimented with field calls and timestamp locking, but none worked out.

    I also don't understand what you mean about slight inconsistensies. Are you talking about using read-committed mode or lesser isolation levels (phantoms?)

    Selecting-for-update or using serialized mode or designing branch/merge structures are some of many ways around that. Besides, optimistic mode is usually last-committer-wins which is worse than read-committed anyway. If it is first-committer-wins, most transactions will abort on hotspots.

    Or am I missing something about the way db4o does optimistic locking? What happends at commit time when 10 transactions have touched the same object and there are phantoms, etc.?
    It has to be true SQL since we want to enable the use of SQL reporting tools.

    Neat.
  9. From my experience with relational databases a large percentage of applications (9 out of 10 ?) with high concurrency has one of the following problems:
    (1) It does not understand locking issues at all and simply does not care about doing things wrong and producing slight inconsistencies every now and then.
    (2) Deadlocks are always threatening the system to come to a halt.
    (3) Optimistic strategies fail frequently and reissuing the business logic imposes a very high workload on the system.
    That's either FUD against relational databases or you've just hanged around with the wrong crowd !
    Transactions and locking issues are no rocket science, any programmer that fails to understand such issues after being lectured on the subject or just reading about the basic principles and then about the implementation-at-hand (eg. Oracle, PostgreSQL etc) is, well, let's just say not incredibly bright.
    Regarding point 2 can you please name a database that when detecting a deadlock brings the system "to a halt" ?
    Regarding point 3 we've never actually come to work drunk enough to even think about implementing optimistic locking ;)

    Cheers!
  10. Prototypes?[ Go to top ]

    Carl,

    I read your tutorial and it appears that to query for objects, you must use the same class as prototype, and then use null for any field you want excluded from the search criteria. It would seem that to make a class fully searchable, any field should be nullable (I'm disregarding primitives) in any combination?
    Doesn't this make it impossible to have object constraints and to ensure that an object is always in a valid state, a cornerstone of OO?
  11. Prototypes?[ Go to top ]

    Nils,

    Query-By-Example is only one way of querying for objects with db4o. We also supply an API to create queries without having to instantiate example objects.

    The small part of the tutorial that is online on the website is *very* limited. The tutorial that comes with the dowload is interactive. It let's you run the examples against a real database from within your web browser, and it will print the results that come back from queries.

    Please download the real tutorial to take a look at the querying API. In the Java download you will find the tutorial in ../db4o-4.5/doc/tutorial/index.html
  12. Db4o rocks anyway[ Go to top ]

    Ofcourse there are issues.

    Carl, listen to the issues of that database guru geezer! He sounds experienced enough to know what he's on about. But people, we're talking about new software here, ofcourse there are issues. None seem very blocking though.

    Ok, so you have to implement some things yourself and okay for those of you with SQL statements on their t-shirts it might not look like heaven, but for a simple guy like me db4o works.

    Why?

    It's fast, it seems to scale and I dont even have to leave my programming language of choice for it. The tutorials are easy to understand and so are the queries themselfs, you're off doing queries in a few minutes.

    Remember this is only the beginning, these database systems probably get more and more mature, with all the support for complex queries I don't seem to need now.

    I got good hopes for db4o