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.

               

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks