...
- All rows of a RowSet will either be accepted or rejected (partial updates are not possible).
- Concurrent RowSet updates are processed serially (not in parallel).
- An optimistic row-level locking scheme is used to ensure that all column values of a single row are consistent between reads and write. If one user changes one column of a row, while another user changes another column of the same row, the first change will be accepted, while the second will be rejected. In other words, you must have read the current row in order to update that row.
- Consistency is not guaranteed between separate rows. This means users can update separate rows concurrently without conflict.
- Query results only reflect the current state of the table. This means an "update lock" is held during the execution of a query. It also means query results may be temporarily unavailable during updates (. Availability is traded for Consistency )since the index that supports the query is on a separte partition from the raw update data. In onther words, the update must be replicated from the "truth" partition to the index partition.
Note: Pagination Consistency - There is a size limit on all query results. This means large query results can only be fetched using pagination, where the caller fetches one page of a query at a time. While the data of a single page is guaranteed to be consistent, there is no guarantee of consistency between pages. In other words, a table can be updated between fetching one page and fetching the next. However, each query result will always return the current etag of the table, so if the etag changes between one page fetch and the next the client can detect the potential inconsistency between page fetches. It is up to the client to decide how to handle this case.
...