The join algorithm is described here so that its cost can be estimated and
compared to other approaches for performing a query. Say that N cursors are
provided for the join operation. According to the order they appear in the
array the cursors are labeled C(1) through C(n), and the keys at each cursor
position are labeled K(1) through K(n).

Using C(1), the join algorithm iterates sequentially through all records
having K(1). This iteration is equivalent to a Cursor.getNextDup operation on the secondary index. The primary key of a
candidate record is determined in this manner. The primary record itself is
not retrieved and the primary database is not accessed.

For each candidate primary key found in step 1, a Btree lookup is
performed using C(2) through C(n), in that order. The Btree lookups are
exact searches to determine whether the candidate record also contains
secondary keys K(2) through K(n). The lookups are equivalent to a Cursor.getSearchBoth operation on the secondary index.
The primary record itself is not retrieved and the primary database is not
accessed.

If any lookup in step 2 fails, the algorithm advances to the next
candidate record using C(1). Lookups are performed in the order of the
cursor array, and the algorithm proceeds to the next C(1) candidate key as
soon as a single lookup fails.

Method Detail

close

The cursors passed to Database.join are not
closed by this method, and should be closed by the caller.

WARNING: To guard against memory leaks, the application should
discard all references to the closed handle. While BDB makes an effort
to discard references from closed objects to the allocated memory for an
environment, this behavior is not guaranteed. The safe course of action
for an application is to discard all references to closed BDB
objects.