Although the Java API parallels the Berkeley DB C++/C interface in many ways, -it differs where the Java language requires. For example, the handle -method names are camel-cased and conform to Java naming patterns. (The -C++/C method names are currently provided, but are deprecated.)

+ Although the Java API parallels the Berkeley DB C++/C + interface in many ways, it differs where the Java language + requires. For example, the handle method names are camel-cased + and conform to Java naming patterns. (The C++/C method names + are currently provided, but are deprecated.) +

Prev	Chapter 5. - Java API -	Chapter 5. Java API	Next

The Java runtime does not automatically close Berkeley DB objects on -finalization. There are several reasons for this. One is that -finalization is generally run only when garbage collection occurs, and -there is no guarantee that this occurs at all, even on exit. Allowing -specific Berkeley DB actions to occur in ways that cannot be replicated seems -wrong. Second, finalization of objects may happen in an arbitrary -order, so we would have to do extra bookkeeping to make sure that -everything was closed in the proper order. The best word of advice is -to always do a close() for any matching open() call. Specifically, the -Berkeley DB package requires that you explicitly call close on each individual -Database and -Cursor object that you opened. Your database -activity may not be synchronized to disk unless you do so.
Some methods in the Java API have no return type, and throw a -DatabaseException when an severe error -arises. There are some notable methods that do have a return value, and -can also throw an exception. The "get" methods in -Database and -Cursor both return 0 when a get -succeeds, DB_NOTFOUND when the key is not found, and throw an -error when there is a severe error. This approach allows the programmer -to check for typical data-driven errors by watching return values -without special casing exceptions. -
An object of type MemoryException is -thrown when a Dbt is too small to hold the corresponding key or data item.
An object of type DeadlockException is -thrown when a deadlock would occur.
An object of type RunRecoveryException, a -subclass of DatabaseException, is thrown when -there is an error that requires a recovery of the database using db_recover utility.
An object of type IllegalArgumentException -a standard Java Language exception, is thrown when there is an error in -method arguments.
An object of type OutOfMemoryError is thrown -when the system cannot provide enough memory to complete the operation -(the ENOMEM system error on UNIX).
If there are embedded nulls in the curslist argument for -Database.join(com.sleepycat.db.Cursor[], com.sleepycat.db.JoinConfig), -they will be treated as the end of the list of cursors, even if you -may have allocated a longer array. Fill in all the cursors in your -array unless you intend to cut it short.
If you are using custom class loaders in your application, make sure -that the Berkeley DB classes are loaded by the system class loader, not a -custom class loader. This is due to a JVM bug that can cause an access -violation during finalization (see the bug 4238486 in Sun Microsystem's -Java Bug Database).
+ The Java runtime does not automatically close + Berkeley DB objects on finalization. There are several + reasons for this. One is that finalization is generally + run only when garbage collection occurs, and there is no + guarantee that this occurs at all, even on exit. Allowing + specific Berkeley DB actions to occur in ways that cannot + be replicated seems wrong. Second, finalization of objects + may happen in an arbitrary order, so we would have to do + extra bookkeeping to make sure that everything was closed + in the proper order. The best word of advice is to always + do a close() for any matching open() call. Specifically, + the Berkeley DB package requires that you explicitly call + close on each individual Database and Cursor object + that you opened. Your database + activity may not be synchronized to disk unless you do + so. +
+ Some methods in the Java API have no return type, + and throw a DatabaseException + when an severe error + arises. There are some notable methods that do have a + return value, and can also throw an exception. The "get" + methods in Database and Cursor both + return 0 when a get succeeds, + DB_NOTFOUND + when the key is not found, and throw an error when there is a severe + error. This approach allows the programmer to check for typical data-driven + errors by watching return values without special casing + exceptions. +
+ An object of type + MemoryException is thrown when a Dbt is + too small to hold the corresponding key or data + item. +
+ An object of type + DeadlockException is thrown when a + deadlock would occur. +
+ An object of type + RunRecoveryException, a subclass of + + DatabaseException, is thrown when there + is an error that requires a recovery of the database + using db_recover utility. +
+ An object of type + IllegalArgumentException a standard Java + Language exception, is thrown when there is an error + in method arguments.
+ An object of type + OutOfMemoryError is thrown when the + system cannot provide enough memory to complete the + operation (the ENOMEM system error on + UNIX). +
+ If there are embedded nulls in the curslist argument for + Database.join(com.sleepycat.db.Cursor[], + com.sleepycat.db.JoinConfig), they will be + treated as the end of the list of cursors, even if you may + have allocated a longer array. Fill in all the cursors in + your array unless you intend to cut it short. +
+ If you are using custom class loaders in your + application, make sure that the Berkeley DB classes are + loaded by the system class loader, not a custom class + loader. This is due to a JVM bug that can cause an access + violation during finalization (see the bug 4238486 in Sun + Microsystem's Java Bug Database). +