public class ClientIndexViewRefactor extends AbstractScaleOutClientIndexView2
A client-side view of a scale-out index as of some timestamp.
This view automatically handles the split, join, or move of index partitions
within the federation. The IDataService throws back a (sometimes
wrapped) StaleLocatorException when it does not have a registered
index as of some timestamp. If this exception is observed when the client
makes a request using a cached PartitionLocator record then the
locator record is stale. The client automatically fetches the locator
record(s) covering the same key range as the stale locator record and the
re-issues the request against the index partitions identified in those
locator record(s). This behavior correctly handles index partition split,
merge, and move scenarios. The implementation of this policy is limited to
exactly three places in the code: AbstractDataServiceProcedureTask,
PartitionedTupleIterator, and DataServiceTupleIterator.
Note that only ITx.UNISOLATED and ITx.READ_COMMITTED
operations are subject to stale locators since they are not based on a
historical committed state of the database. Historical read and
fully-isolated operations both read from historical committed states and the
locators are never updated for historical states (only the current state of
an index partition is split, joined, or moved - the historical states always
remain behind).
batchOnly, ERR_ABORT_TX, ERR_NEW_TX, fed, log, name, NON_BATCH_API, readConsistent, taskTimeout, timestamp, WARN| Constructor and Description |
|---|
ClientIndexViewRefactor(AbstractScaleOutFederation fed,
String name,
long timestamp,
IMetadataIndex metadataIndex)
Create a view on a scale-out index.
|
| Modifier and Type | Method and Description |
|---|---|
protected void |
runTasks(boolean parallel,
ArrayList<com.bigdata.service.ndx.AbstractDataServiceProcedureTask> tasks)
Runs a set of tasks.
|
getRecursionDepth, submit, submit, submitcontains, contains, getCounter, getCounters, getDataService, getFederation, getIndexMetadata, getMetadataIndex, getMetadataIndexMetadata, getMetadataService, getName, getResourceMetadata, getThreadPool, getTimestamp, getTupleSerializer, insert, insert, locatorScan, lookup, lookup, newWriteBuffer, putIfAbsent, rangeCount, rangeCount, rangeCountExact, rangeCountExactWithDeleted, rangeIterator, rangeIterator, rangeIterator, remove, remove, splitKeys, splitKeys, staleLocator, submit, submit, submit, toStringpublic ClientIndexViewRefactor(AbstractScaleOutFederation fed, String name, long timestamp, IMetadataIndex metadataIndex)
fed - The federation containing the index.name - The index name.timestamp - A transaction identifier, ITx.UNISOLATED for the
unisolated index view, ITx.READ_COMMITTED, or
timestamp for a historical view no later than
the specified timestamp.metadataIndex - The IMetadataIndex for the named scale-out index as of
that timestamp. Note that the IndexMetadata on this
object contains the template IndexMetadata for the
scale-out index partitions.protected void runTasks(boolean parallel,
ArrayList<com.bigdata.service.ndx.AbstractDataServiceProcedureTask> tasks)
Note: If AbstractScaleOutClientIndexView2.getRecursionDepth() evaluates to a value larger than
zero then the task(s) will be forced to execute in the caller's thread.
StaleLocatorExceptions are handled by the recursive application
of submit(). These recursively submitted tasks are forced
to run in the caller's thread by incrementing the
AbstractScaleOutClientIndexView2.getRecursionDepth() counter. This is done to prevent the thread
pool from becoming deadlocked as threads wait on threads handling stale
locator retries. The deadlock situation arises as soon as all threads in
the thread pool are waiting on stale locator retries as there are no
threads remaining to process those retries.
runTasks in class AbstractScaleOutClientIndexView2parallel - true iff the tasks MAY be run in parallel.tasks - The tasks to be executed.Copyright © 2006–2019 SYSTAP, LLC DBA Blazegraph. All rights reserved.