Ldapd uses jdbm

2003-01-28
2003-01-31
  • Alex Karasulu
    Alex Karasulu
    2003-01-28

    Our pure Java based LDAP server ldapd uses jdbm in one of its pluggable backend modules.  It looks like jdbm outperforms the native Berkeley backend by a factor of 4 on writes and at lease a factor of 2 on reads.  Believe it or not Jdbm is much better.  Berekeley seems to loose alot in crossing the JNI barrier.  Great work Alex!

     
    • Alex Boisvert
      Alex Boisvert
      2003-01-29

      That's interesting news.  First an interesting project using JDBM and secondo, some positive feedback on the performance side.

      I've looked at the manifest and roadmap for the LDAPD project and it seems like a very worthwhile effort.  Good luck with LDAPD and let me know if and how I can help you.

      regards,
      alex

       
    • Alex Karasulu
      Alex Karasulu
      2003-01-30

      Alex,

      Thanks alot first for making Jdbm and secondly for volunteering.  Perhaps you could take a look at the ldapd-modjdbm backend module's implementation using Jdbm and give me a rough idea of what you think.  Namely I'm wondering if I'm using Jdbm optimally.  I have a wrapper around Jdbm called Table in the ldapd.server.backend.jdbm.table package.  The wrapper's role is mainly to transduce IOExceptions to BackendExceptions and to convert your TupleBrowser into a Cursor.  This is where I think you can briefly look to see if I'm using the BTree correctly.  It all works like a champion by the way.  I just was interested in your feedback.  For example, should I be using the top level JDBMRecordManager and JDBMHashtable classes rather than directly using a BTree?

      Also if interested let us know - you're more than welcome to join the team.  BTW, we are not only using Jdbm but OpenJMS in our project - another good project by the intalio studs.

      Thanks and talk to you soon,
      Alex

       
      • Alex Boisvert
        Alex Boisvert
        2003-01-31

        Using the BTree directly is fine.  As a matter of fact, JDBMRecordManager and JDBMHashtable have disappeared in the CVS version, since those were only wrappers.  This simplifies the API (refactored).

        Your approach seems okay, wrapping the IOException/Browser is a natural way when abstracting back ends.  You want your own abstractions to hide implementation details.

        I am not currently available to join your project.  If I had more time (I've always got interest), I'd be spending more time improving JDBM in the first place ;)

        best,
        alex