|Modifier and Type||Field and Description|
A constant that SHOULD used as the timestamp for read-committed (non-transactional dirty reads) operations.
The constant that SHOULD used as the timestamp for an unisolated read-write operation.
|Modifier and Type||Method and Description|
Return an array of the resource(s) (the named indices) on which the transaction has written (the isolated index(s) that absorbed the writes for the transaction).
Return an isolated view onto a named index.
When true, the transaction has an empty write set.
isAborted, isActive, isCommitted, isComplete, isPrepared, isReadOnly
static final long UNISOLATED
Wed Dec 31 19:00:00 EST 1969when interpreted as a
static final long READ_COMMITTED
Wed Dec 31 18:59:59 EST 1969when interpreted as a
If you want a scale-out index to be read consistent over multiple
operations, then use
IIndexStore.getLastCommitTime() when you
specify the timestamp for the view. The index will be as of the specified
commit time and more recent commit points will not become visible.
AbstractTasks that run with read-committed isolation provide a
read-only view onto the most recently committed state of the indices on
which they read. However, when a process runs a series of
AbstractTasks with read-committed isolation the view of the
index in each distinct task will change if concurrenct processes commit
writes on the index (some constructs, such as the scale-out iterators,
provide read-consistent views for the last commit time). Further, an
index itself can appear or disappear if concurrent processes drop or
register that index.
A read-committed transaction imposes fewer constraints on when old resources (historical journals and index segments) may be released. For this reason, a read-committed transaction is a good choice when a very-long running read must be performed on the database. Since a read-committed transaction does not allow writes, the commit and abort protocols are identical.
However, split/join/move operations can cause locators to become invalid
for read-committed (and unisolated) operations. For this reason, it is
often better to specify "read-consistent" semantics by giving the
lastCommitTime for the
ILocalBTreeView getIndex(String name)
IsolatedFusedView. Reads that miss on the
IsolatedFusedViewwill read through named index as of the ground state of this transaction. If the transaction is read-only then the index will not permit writes.
#prepare(long), the write set of each
IsolatedFusedView will be validated against the then current commited
state of the named index.
#mergeDown(), the validated write sets will be merged down
onto the then current committed state of the named index.
Copyright © 2006-2015 SYSTAP, LLC. All Rights Reserved.