Cursors which are opened with a transaction instance are transactional cursors and may be used by multiple threads, but only serially. That is, the application must serialize access to the handle. Non-transactional cursors, opened with a null transaction instance, may not be used by multiple threads.
If the cursor is to be used to perform operations on behalf of a transaction, the cursor must be opened and closed within the context of that single transaction.
Once the cursor {@link #close} method has been called, the handle may notbe accessed again, regardless of the {@code close} method's success orfailure, with one exception: the {@code close} method itself may be calledany number of times to simplify error handling.
To obtain a cursor with default attributes:
Cursor cursor = myDatabase.openCursor(txn, null);
To customize the attributes of a cursor, use a CursorConfig object.
CursorConfig config = new CursorConfig(); config.setReadUncommitted(true); Cursor cursor = myDatabase.openCursor(txn, config);
Modifications to the database during a sequential scan will be reflected in the scan; that is, records inserted behind a cursor will not be returned while records inserted in front of a cursor will be returned.
The {@link DatabaseEntry#setPartial DatabaseEntry Partial} property canbe used to optimize in certain cases. This provides varying degrees of performance benefits that depend on the specific operation and use of {@code READ_UNCOMMITTED} isolation, as described below.
When retrieving a record with a {@link Database} or {@link Cursor}method, if only the key is needed by the application then the retrieval of the data item can be suppressed using the Partial property. If {@code setPartial(0, 0, true)} is called for the {@code DatabaseEntry} passed asthe data parameter, the data item will not be returned by the {@code Database} or {@code Cursor} method.
Suppressing the return of the data item potentially has a large performance benefit when the {@code READ_UNCOMMITTED} isolation mode isused. In this case, if the record data is not in the JE cache, it will not be read from disk. The performance benefit is potentially large because random access disk reads may be reduced. Examples are:
For other isolation modes ( {@code READ_COMMITTED}, {@code REPEATABLE_READ} and {@code SERIALIZABLE}), the performance benefit is not as significant. In this case, the data item must be read into the JE cache if it is not already present, in order to lock the record. The only performance benefit is that the data will not be copied from the JE cache to the application's entry parameter.
For information on specifying isolation modes, see {@link LockMode}, {@link CursorConfig} and {@link TransactionConfig}.
The Partial property may also be used to retrieve or update only a portion of a data item. This avoids copying the entire record between the JE cache and the application data parameter. However, this feature is not currently fully optimized, since the entire record is always read or written to the database, and the entire record is cached. A partial update may be performed only with {@link Cursor#putCurrent Cursor.putCurrent}.
In limited cases, the Partial property may also be used to retrieve a partial key item. For example, a {@code DatabaseEntry} with a Partialproperty may be passed to {@link #getNext getNext}. However, in practice this has limited value since the entire key is usually needed by the application, and the benefit of copying a portion of the key is generally very small. Partial key items may not be passed to methods that use the key as an input parameter, for example, {@link #getSearchKey getSearchKey}. In general, the usefulness of partial key items is very limited.
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |