Why

2000-04-13
2000-04-18
  • Ry4an Brase
    Ry4an Brase
    2000-04-13

    Why isn't the file format compatable with gdbm?  Why not just use the Java implementation of SDBM (like jazilla does) which does have C/Perl compatabile data files?  If you are implementing another DB in java, why not do the excellent Berkley DB?

    SDBM - https://sourceforge.net/project/?form_grp=357

     
    • Cees de Groot
      Cees de Groot
      2000-04-18

      I'll check out sdbm - I've searched around, but couldn't find anything like gdbm for Java. If SDBM fills this purpose, I'll kill the jdbm project right away :-)

       
    • Cees de Groot
      Cees de Groot
      2000-04-18

      I've scanned SDBM, and while it looks promising, there is one difference with the JDBM project. The JDBM project goes a long way to make sure that it works within transaction boundaries, and in fact one of the goals is to make it into an XA Resource. This lets it function reliably in transactional environments, be it as persistence support for transaction managers or as a managed resource.

      This is not easily done with existing *dbm formats, so therefore JDBM has an incompatible format (a single file containing all data; in principle this file can house a complete database; and a transaction log file).

       
      • Ry4an Brase
        Ry4an Brase
        2000-04-18

        I now understand the primary difference between JDBM and the others out there (single data file), but I guess I don't understand why that makes use in a transactional environment all that much easier?  Is it just locking/sharing requirements?

         
        • Cees de Groot
          Cees de Groot
          2000-04-18

          One advantage is that you cannot run out of arbitrary platform resources, like file handles. Furthermore, you can just deal, internally, with blocks of data and their location within the file, which is a bit simpler than other methods. Apart from that, any system is as good as any other one (single file, multiple files); as compatibility on the file level is not a requirement, I just cooked up a quite complete single-file, transactional format.

           
          • Ry4an Brase
            Ry4an Brase
            2000-04-18

            Got it.  If you haven't seen it yet you should definately check out IronDoc.  http://www.best.com/~mccusker/irondoc/irondoc.htm it's not a completed system, and it's not in Java, but the guy whose doing it is a data storage ninja whose been working on a single-file system for a long time.

             
            • Ry4an Brase
              Ry4an Brase
              2000-04-18

              It's at http://www.best.com/~mccusker/fe/fe.htm Here's the first paragraph from that page.

              "IronDoc is a portable, cross-platform database of the structured storage variety, which typically puts all content in one file inside an operating system's file system. Inside this one file, IronDoc creates and maintains an embedded file system under an app framework's control, using structures specific to developer needs. The main low level features are variable length blobs (the same as files), and highly efficient and specializable btree dictionaries for key-to-value maps. High level features are composed by applying these low level blobs and dicts."

              He doesn't have a working system yet, but he's got a lot of good thinking done.