#include <db.h>

int
DB_SEQUENCE->get(DB_SEQUENCE *seq,
    DB_TXN *txnid, int32_t delta, db_seq_t *retp, u_int32_t flags);

Description: DB_SEQUENCE->get

The DB_SEQUENCE->get method returns the next available element in the sequence and changes the sequence value by delta. The value of delta must be greater than zero. If there are enough cached values in the sequence handle then they will be returned. Otherwise the next value will be fetched from the database and incremented (decremented) by enough to cover the delta and the next batch of cached values.

For maximum concurrency a non-zero cache size should be specified prior to opening the sequence handle and DB_TXN_NOSYNC should be specified for each DB_SEQUENCE->get method call.

By default, sequence ranges do not wrap; to cause the sequence to wrap around the beginning or end of its range, specify the DB_SEQ_WRAP flag to the DB_SEQUENCE->set_flags method.

The DB_SEQUENCE->get method will return EINVAL if the record in the database is not a valid sequence record, or the sequence has reached the beginning or end of its range and is not configured to wrap.

Parameters

delta

Specifies the amount to increment or decrement the sequence.

flags

The flags parameter must be set to 0 or by bitwise inclusively OR'ing together one or more of the following values:

DB_TXN_NOSYNC

If the operation is implicitly transaction protected (the txnid argument is NULL but the operation occurs to a transactional database), do not synchronously flush the log when the transaction commits.

retp

retp points to the memory to hold the return value from the sequence.

txnid

If the operation is part of an application-specified transaction, the txnid parameter is a transaction handle returned from DB_ENV->txn_begin; otherwise NULL. If no transaction handle is specified, but the operation occurs in a transactional database, the operation will be implicitly transaction protected. No txnid handle may be specified if the sequence handle was opened with a non-zero cache size.

If the underlying database handle was opened in a transaction, calling DB_SEQUENCE->get may result in changes to the sequence object; these changes will be automatically committed in a transaction internal to the Berkeley DB library. If the thread of control calling DB_SEQUENCE->get has an active transaction, which holds locks on the same database as the one in which the sequence object is stored, it is possible for a thread of control calling DB_SEQUENCE->get to self-deadlock because the active transaction's locks conflict with the internal transaction's locks. For this reason, it is often preferable for sequence objects to be stored in their own database.

Class

See Also