Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Can anyone help me to figure out this issue. I'm getting exception when i try Htree.load
at java.security.AccessController.doPrivileged(Native Method)
at java.lang.Class.forName0(Native Method)
Thanks in advance
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?
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.
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.
nope.. i've only these options set.
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.
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...
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.