Berkeley DB Java Edition
Frequently Asked Questions

See the FAQ section of the JE blog for the latest FAQ entries.

Why is ClassNotFoundException thrown when adding a record to the database, when a SerialBinding is used?
This problem occurs if you copy the je.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 je.jar is specified in the classpath.

An example of the exception is:
```
collections.shipment.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)
...
```
How do I retrieve duplicate records from a database?
Database records that have the same key are duplicate records. When using the com.sleepycat.je API, you need to position a Cursor at the desired key and then retrieve the subsequent duplicate records.
The Getting Started Guide has a good section on how to position your cursor: Search For Records and then how to retrieve the rest of the duplicates: Working with Duplicates.
Does Berkeley DB Java Edition run on J2ME?
Berkeley DB Java Edition requires a J2SE 1.4.2 or later Java VM. There are no plans to support J2ME at this time. As always, we try to listen to feature requests from our customers. If you are very interested in J2ME support you should let us know by contacting our sales department.
Can a Berkeley DB database be used by Berkeley DB Java Edition?
Data files can not be shared between Berkeley DB and Berkeley DB Java Edition. Because of fundamental architectural differences, the on disk format differs in the two products.
Both products do share the same format for the data dump and load utilities (com.sleepycat.je.util.DbDump, com.sleepycat.je.util.DbLoad), so you can import and export data between the two products.
Why do iterators returned by the JE collections API need to be explicitly closed by the caller?
If you obtain an Iterator from a StoredCollection, it is always a StoredIterator and must be explicitly closed. Closing the iterator is necessary to release the locks held by the underlying Cursor. To avoid performance problems, is important to close the cursor as soon as it is no longer needed.
Since the Java Iterator interface has no close() method, the close() method on the StoredIterator class must be used. Alternatively, to avoid casting the Iterator to a StoredIterator, you can call the StoredIterator.close(Iterator) static method; this method will do nothing if the argument given is not a StoredIterator.
To ensure that an Iterator is always closed, even if an exception is thrown, use a finally clause. For example:
```
    Iterator i = myStoredCollection.iterator();
    try {
        while (i.hasNext()) {
            Object o = i.next();
            // do some work
        }
    } finally {
        StoredIterator.close(i);
    }
```
How can the JE collections API be used with other components that do not close iterators?
There are times when you may need to pass a StoredCollection to a component that will call its iterator() method. If that component is not aware of the StoredIterator class, naturally it will not call the StoredIterator.close() method. This will cause a leak of unclosed Cursors, which can cause performance problems. For more on this topic, see the FAQ "Why do iterators returned by the JE collections API need to be explicitly closed by the caller?".
If the component cannot be modified to call StoredIterator.close(), the only solution is to copy the elements from the StoredCollection to a standard Java collection, and pass the resulting copy to the component. The simplest solution is to call the StoredCollection.toList() method to copy the StoredCollection to a standard Java ArrayList.
If the StoredCollection is large and only some of the elements need to be passed to the component, it may be undesirable to call the toList() method on the entire collection since that will copy all elements from the database into memory. There are two ways to create a standard Java collection containing only the needed elements:
1. A submap or subset of the StoredCollection can be created, and then the toList() method can be called on that submap or subset. The standard Java SortedMap and SortedSet methods may be used for creating a submap or a subset. The resulting collection will be a StoredCollection, and its toList() method can then be called.
2. The elements of the StoredCollection can be explicitly iterated, selected and copied to an ArrayList or another standard Java collection. There are many ways to implement such application specific filtering using the collections API.
Does JE support high performance LOBs (large objects)?
JE supports get() and put() operations with partial data. However, this feature is not fully optimized, since the entire record is always read or written to the database, and the entire record is cached.

So the only advantage (currently) to using partial get() and put() operations is that only a portion of the record is copied to or from the buffer supplied by the application. In the future Sleepycat may provide optimizations of this feature, but until then we cannot claim that JE has high performance LOB support.

For more information on partial get() and put() operations please see:

DatabaseEntry.setPartial()

Berkeley DB Java EditionFrequently Asked Questions

Berkeley DB Java Edition
Frequently Asked Questions