Table of Contents
There are several ways to retrieve table rows from the store. You can:
Retrieve a single row at a time using
TableAPI.get().
Retrieve rows associated with a shard key (which is based on
at least part of your primary keys) using either
TableAPI.multiGet()
or
TableAPI.multiGetIterator().
Retrieve table rows that share a shard key, or an
index key, using TableAPI.tableIterator().
Each of these are described in the following sections.
One of three exceptions can occur when you attempt a read operation
in the store. The first of these is
ConsistencyException.
This exception indicates that the operation cannot be completed
because the consistency policy cannot be met. For more
information, see
Consistency Guarantees.
The second exception is
RequestTimeoutException. This means that
the operation could not be completed within the amount of time
provided by the store's timeout property. This probably
indicates a store that is attempting to service too many read
requests all at once. Remember that your data is partitioned
across the shards in your store, with the partitioning
occurring based on your shard keys. If you designed your keys
such that a large number of read requests are occurring against
a single key, you could see request timeouts even if some of
the shards in your store are idle.
A request timeout could also be indicative of a network problem that is causing the network to be slow or even completely unresponsive.
To handle a RequestTimeoutException,
you could simply log the error and move on, or you could pause for
a short period of time and then retry the operation. You could
also retry the operation, but use a longer timeout value.
Finally, you can receive a general
FaultException, which indicates that
some exception occurred which is neither a problem with
consistency nor a problem with the request timeout. Your only
recourse here is to either log the error and move along, or
retry the operation.