Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

Htree.load() fails - jdbm.hash.HashDirectory

Prassoon
2006-08-07
2013-06-03
  • Prassoon
    Prassoon
    2006-08-07

    Hi there

    Can anyone help me to figure out this issue. I'm getting exception when i try Htree.load

    java.lang.ClassNotFoundException: jdbm.hash.HashDirectory
            at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
            at java.security.AccessController.doPrivileged(Native Method)
            at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
            at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
            at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
            at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
            at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
            at java.lang.Class.forName0(Native Method)
            at java.lang.Class.forName(Class.java:242)
            at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:574)
            at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1538)
            at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460)
            at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693)
            at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
            at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
            at jdbm.helper.Serialization.deserialize(Serialization.java:93)
            at jdbm.helper.DefaultSerializer.deserialize(DefaultSerializer.java:97)
            at jdbm.recman.BaseRecordManager.fetch(BaseRecordManager.java:341)
            at jdbm.recman.CacheRecordManager.fetch(CacheRecordManager.java:263)
            at jdbm.recman.CacheRecordManager.fetch(CacheRecordManager.java:242)
            at jdbm.htree.HTree.load(HTree.java:113)

    Thanks in advance

     
    • Kevin Day
      Kevin Day
      2006-08-07

      Sounds like the deserializer is failing when trying to reconstruct an object of class jdbm.hash.HashDirectory.

      This is a pretty basic component of the HTree piece of jdbm, so if the class loader isn't loading it, there is either something wrong with your jdbm distro, or the class path...

      Before you call the load() method, see if you can instantiate a new HashDirectory instance using the following line:

      HashDisrectory testHD = new HashDirectory();

      Does this compile?  If it does, when you launch the app, does it fail at this line now?

      Also, which jdbm distro are you using?  Maybe there is a problem in a jar file somewhere that needs to be fixed.

      If you open the jdbm jar file in winzip (or equivalent), you should be able to find the jdbm/htree/HashDirectory.class file inside it...  Can you?

      - K

       
    • Prassoon
      Prassoon
      2006-08-08

      Hi K

      Thanks for the reply. I use JDBM 1.0 on Solaris, Yes the class is present in the jar. It seems like the db file got corrupted for some reason. When i clean up the db files it is working fine.

      Cheers
      Prassoon.

       
      • Kevin Day
        Kevin Day
        2006-08-08

        Hmmmm - were you running with transactions disabled while you made database updates?

        I'm asking because it is quite difficult to corrupt a jdbm db file (short of a physical disk error, or maliciously damaging the file with a non-jdbm app).

        With transactions disabled, the two-phase commit would have been disabled, and the db file could be corrupted if the process was terminated.

        - K

         
    • Prassoon
      Prassoon
      2006-08-18

      nope.. i've only these options set.

      props.setProperty(RecordManagerOptions.AUTO_COMMIT, "jdbm.autoCommit");
      props.setProperty(RecordManagerOptions.THREAD_SAFE, "jdbm.threadSafe");

      i guess not setting DISABLE_TRANSACTIONS means it is enabled, right? I cant find any other ways to explicitly enable it.

      I was having two different applications accessing the same db, which are not supposed to work concurrently. Thats the reason for db corruption, i think.

      Thanks a lot.

       
      • Kevin Day
        Kevin Day
        2006-08-18

        Oh yes - having two apps messing with the same db file at the same time is a recipe for disaster.

        I thought that jdbm winds up with an exclusive lock on the file, but maybe thats OS dependent...

        - K

         
    • Prassoon
      Prassoon
      2006-08-20

      I think JDBM itself doesnt have any file locking mechanism. I have a class which does the jdbm operations; in runtime multiple threads will be using it from within a process and from other processes as well. Here i had to acquire the file lock explicitly in order to make it work properly on a multi-process environment.

      Cheers
      Prassoon.