public interface KVTransaction extends KVStore
KVDatabase transaction API.
Provides a transactional view of a KVStore.
Instances may throw KVTransactionException during any operation if the transaction cannot be continued.
In particular, StaleTransactionException is thrown by a transaction that is no longer open, and
RetryTransactionException is thrown when the transaction should be retried due to a transient
problem (such as a write conflict with another transaction).
When RetryTransactionException is thrown by commit(), the transaction may have actually been committed.
Therefore, transactions should be written to be idempotent.
No matter what state it is in, instances must support invoking rollback() at any time.
If an instance throws a KVTransactionException, the transaction should be implicitly rolled back.
Any subsequent operation other than rollback() should throw StaleTransactionException.
Except for rollback() and methods that just query status, implementations must throw StaleTransactionException
if commit() or rollback() has already been invoked, or if the KVTransaction instance is no longer usable
for some other reason. In particular, implementations should throw TransactionTimeoutException if an operation
is attempted on a transaction that has been held open past some maximum allowed time limit.
Implementations are responsible for ensuring modifications to byte[] arrays after method
invocations do no harm. This usually means byte[] array parameters and return values must be copied.
Implementations are not required to support accessing keys that start with 0xff,
and if not may throw IllegalArgumentException if such keys are accessed.
Note: for some implementations, the data read from a transaction that is never commit()'ed is
not guaranteed to be up to date.
| Modifier and Type | Method and Description |
|---|---|
void |
commit()
Commit this transaction.
|
KVDatabase |
getKVDatabase()
Get the
KVDatabase with which this instance is associated. |
boolean |
isReadOnly()
Determine whether this transaction is read-only.
|
CloseableKVStore |
mutableSnapshot()
Create a mutable copy of the database content represented by this transaction.
|
void |
rollback()
Cancel this transaction, if not already canceled.
|
void |
setReadOnly(boolean readOnly)
Enable or disable read-only mode.
|
void |
setTimeout(long timeout)
Change the timeout for this transaction from its default value (optional operation).
|
Future<Void> |
watchKey(byte[] key)
Watch a key to monitor for changes in its value.
|
adjustCounter, apply, decodeCounter, encodeCounter, get, getAtLeast, getAtMost, getRange, getRange, getRange, put, remove, removeRange, removeRangeKVDatabase getKVDatabase()
KVDatabase with which this instance is associated.void setTimeout(long timeout)
timeout - transaction timeout in milliseconds, or zero for unlimitedUnsupportedOperationException - if this transaction does not support timeoutsIllegalArgumentException - if timeout is negativeStaleTransactionException - if this transaction is no longer usableboolean isReadOnly()
Default is false.
StaleTransactionException - if this transaction is no longer usablevoid setReadOnly(boolean readOnly)
Read-only transactions allow mutations, but all changes are discarded on commit().
Some implementations may impose one or more of the following restrictions on this method:
setReadOnly() may only be invoked prior to accessing data;setReadOnly() may only be invoked prior to mutating data; and/or
Note: for some implementations, the data read from a transaction that is never commit()'ed is
not guaranteed to be up to date, even if that transaction is read-only.
Default is false.
readOnly - read-only settingIllegalStateException - if the implementation doesn't support changing read-only status at this timeStaleTransactionException - if this transaction is no longer usableFuture<Void> watchKey(byte[] key)
When this method is invoked, key's current value (if any) as read by this transaction is remembered. The returned
Future completes if and when a different value for key is subsequently committed by some transaction,
including possibly this one. This includes creation or deletion of the key.
Key watches outlive the transaction in which they are created, persisting until they complete or are
cancel()'ed. When a KVDatabase is KVDatabase.stop()'ed, all outstanding
key watches are implicitly cancel()'ed.
Caveats
Key watches are not without overhead; applications should avoid overuse. For example, consider creating a
single key that is used to consolidate modifications to some set of keys; at the Permazen layer, modification
to multiple objects and/or fields can detected and consolidated using an
@OnChange method that increments a single Counter
field, whose key is then watched (to determine the key corresponding to a Java model object field, use
JTransaction.getKey()).
Conceptually, detection of changes behaves as if by a background thread that periodically creates a new transaction and reads the key's value (the actual implementation will likely be more efficient). This means a change that is quickly reverted could be missed, and that multiple changes could occur before notification. In addition, spurious notifications may occur, where the key's value has not changed.
A key watch is only guaranteed to be valid if the transaction in which it was created successfully commits.
In particular, nothing is specified about how or whether Futures associated with failed transactions complete,
so the Futures returned by this method should not be relied on until after a successful commit (perhaps with
the help of a transaction callback).
Key watch support is optional; instances that don't support key watches throw UnsupportedOperationException.
Some implementations may only support watching a key that already exists.
Note: many KVDatabase implementations actually return a
ListenableFuture. However, listeners must not perform any
long running or blocking operations. Also, because the semantics of RetryTransactionException allow for
the possibility that the transaction actually did commit, "duplicate" listener notifications could occur.
Key watch Futures that have not completed yet, but are no longer needed, must be cancel()'ed
to avoid memory leaks.
Key watch support is indepdendent of whether the transaction is read-only.
key - the key to watchFuture that returns key when the value associated with key is modifiedStaleTransactionException - if this transaction is no longer usableRetryTransactionException - if this transaction must be retried and is no longer usableKVDatabaseException - if an unexpected error occursUnsupportedOperationException - if this instance does not support key watchesIllegalArgumentException - if key starts with 0xff and such keys are not supportedIllegalArgumentException - if key is nullJTransaction.getKey()void commit()
Note that if this method throws a RetryTransactionException,
the transaction was either successfully committed or rolled back. In either case,
this instance is no longer usable.
Note also for some implementations, even read-only transactions must be commit()'ed in order for the
data accessed during the transaction to be guaranteed to be up to date.
StaleTransactionException - if this transaction is no longer usableRetryTransactionException - if this transaction must be retried and is no longer usablevoid rollback()
After this method returns, this instance is no longer usable.
Note: for some implementations, rolling back a transaction invalidates guarantees about the the data read
during the transaction being up to date, even if the transaction was setReadOnly().
This method may be invoked at any time, even after a previous invocation of
commit() or rollback(), in which case the invocation will be ignored.
In particular, this method should not throw StaleTransactionException.
CloseableKVStore mutableSnapshot()
The returned CloseableKVStore should be mutable, but all changes should remain private until
close() is invoked, at which time they should be discarded.
That is, the CloseableKVStore it is completely independent from this transaction
(subsequent changes to either one do not affect the other).
Note that as with any other information extracted from a KVTransaction, the returned content
should not be considered valid until this transaction has been successfully committed.
The returned CloseableKVStore should be promply close()'d when no longer
needed to release any underlying resources. In particular, the caller must ensure that the CloseableKVStore
is close()'d even if this transaction's commit fails. This may require
adding a transaction synchronization callback, etc.
This is an optional method; only some underlying key/value store technologies can efficiently support it.
Implementations should throw UnsupportedOperationException if not supported.
UnsupportedOperationException - if this method is not supportedStaleTransactionException - if this transaction is no longer usableRetryTransactionException - if this transaction must be retried and is no longer usableCopyright © 2021. All rights reserved.