public interface ITx extends ITxState
Interface for transaction state on the client.
Modifier and Type | Field and Description |
---|---|
static long |
READ_COMMITTED
A constant that SHOULD used as the timestamp for read-committed
(non-transactional dirty reads) operations.
|
static long |
UNISOLATED
The constant that SHOULD used as the timestamp for an unisolated
read-write operation.
|
Modifier and Type | Method and Description |
---|---|
String[] |
getDirtyResource()
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).
|
ILocalBTreeView |
getIndex(String name)
Return an isolated view onto a named index.
|
boolean |
isEmptyWriteSet()
When true, the transaction has an empty write set.
|
isAborted, isActive, isCommitted, isComplete, isPrepared, isReadOnly
getReadsOnCommitTime, getStartTimestamp
static final long UNISOLATED
Wed Dec 31 19:00:00 EST 1969
when
interpreted as a Date
.static final long READ_COMMITTED
Wed Dec 31 18:59:59 EST 1969
when interpreted as a
Date
.
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.
AbstractTask
s 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
AbstractTask
s 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 IIndexStore
.
boolean isEmptyWriteSet()
ILocalBTreeView getIndex(String name)
IsolatedFusedView
. Reads that
miss on the IsolatedFusedView
will 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.
During #prepare(long)
, the write set of each
IsolatedFusedView
will be validated against the then current committed
state of the named index.
During #mergeDown()
, the validated write sets will be merged down
onto the then current committed state of the named index.
name
- The index name.null
if no index is registered
under that name.IllegalArgumentException
- if name is null
IllegalStateException
- if the transaction is not active.String[] getDirtyResource()
Copyright © 2006–2019 SYSTAP, LLC DBA Blazegraph. All rights reserved.