### Berkeley DB Reference Guide: Java API |

### Java FAQ

1. On what platforms is the Berkeley DB Java API supported?

   All platforms supported by Berkeley DB that have a J2SE 1.3.1 compliant JVM.

2. Will the Berkeley DB Java API function properly when using Java version 1.4?

   The minimum required version is J2SE 1.3. Sun claims, and it has been our experience, that for the most part 1.4.1 is backwards compatible with 1.3.1. It is highly likely it will, we recommend that you run the supplied test suites against the specific Java VM on the specific platform on which you plan to ship your product to ensure compatibility.

3. How does the Berkeley DB Java API relate to the J2EE standard?

   The Berkeley DB Java API does not currently implement any part of the J2EE standard. That said, it does implement the implicit standard for Java Java Collections. The concept of a transaction exists in several Java packages (J2EE, XA, JINI to name a few). Support for these APIs will be added based on demand in future versions of Berkeley DB.

4. How should I incorporate db.jar and the db native library into a Tomcat or other J2EE application servers?

   Tomcat and other J2EE application servers have the ability to rebuild and reload code automatically. When using Tomcat this is the case when "reloadable" is set to "true". If your WAR file includes the db.jar it too will be reloaded each time your code is reloaded. This causes exceptions as the native library can't be loaded more than once and there is no way to unload native code. The solution is to place the db.jar in $TOMCAT_HOME/common/lib and let Tomcat load that library once at start time rather than putting it into the WAR that gets reloaded over and over.

5. Can I use the Berkeley DB Java API from within a EJB, a Servlet or a JSP page?

   Yes. The Berkeley DB Java API can be used from within all the popular J2EE application servers in many different ways.

6. During one of the first calls to the Berkeley DB Java API, a DbException is thrown with a "Bad file number" or "Bad file descriptor" message.

   There are known large-file support bugs under JNI in various releases of the JDK. Please upgrade to the latest release of the JDK, and, if that does not solve the problem, disable big file support using the --disable-largefile configuration option.

7. How can I use native methods from a debug build of the Java library?

   The Berkeley DB Java code checks a system property for the library name before defaulting to the released library. On Windows, run as follows (note the 'd' at the end):

   >     % java -Dsleepycat.db.libname=libdb_java-VERSIONd

   On UNIX, try:

   >     % java -Dsleepycat.db.libname=db_java_g-VERSION

8. Why is ClassNotFoundException thrown when adding a record to the database, when a SerialBinding is used?

   This problem occurs if you copy the db.jar file into the Java extensions (ext) directory. This will cause the database code to run under the System class loader, and it won't be able to find your application classes.

   You'll have to actually remove db.jar from the Java extension directory. If you have more than one installation of Java, be sure to remove it from all of them. This is necessary even if db.jar is specified in the classpath.

   An example of the exception is:

   >     collections.ship.basic.SupplierKey
   >     at java.net.URLClassLoader$1.run(Unknown Source)
   >     at java.security.AccessController.doPrivileged(Native Method)
   >     at java.net.URLClassLoader.findClass(Unknown Source)
   >     at java.lang.ClassLoader.loadClass(Unknown Source)
   >     at java.lang.ClassLoader.loadClass(Unknown Source)
   >     at java.lang.ClassLoader.loadClassInternal(Unknown Source)
   >     at java.lang.Class.forName0(Native Method)
   >     at java.lang.Class.forName(Unknown Source)
   >     at com.sleepycat.bind.serial.StoredClassCatalog.getClassInfo(StoredClassCatalog.java:211)
   >     ...

Copyright (c) 1996-2005 Sleepycat Software, Inc. - All rights reserved.