public class ReadOnlyKeyColumnValueStore extends KCVSProxy
KeyColumnValueStore and throws exceptions when a mutation is attempted.NO_ADDITIONS, NO_DELETIONS| Constructor and Description |
|---|
ReadOnlyKeyColumnValueStore(KeyColumnValueStore store) |
| Modifier and Type | Method and Description |
|---|---|
void |
acquireLock(StaticBuffer key,
StaticBuffer column,
StaticBuffer expectedValue,
StoreTransaction txh)
Attempts to claim a lock on the value at the specified
key and
column pair. |
void |
mutate(StaticBuffer key,
List<Entry> additions,
List<StaticBuffer> deletions,
StoreTransaction txh)
Verifies acquisition of locks
txh from previous calls to
KeyColumnValueStore.acquireLock(StaticBuffer, StaticBuffer, StaticBuffer, StoreTransaction)
, then writes supplied additions and/or deletions to
key in the underlying data store. |
public ReadOnlyKeyColumnValueStore(KeyColumnValueStore store)
public void acquireLock(StaticBuffer key, StaticBuffer column, StaticBuffer expectedValue, StoreTransaction txh) throws BackendException
KeyColumnValueStorekey and
column pair. These locks are discretionary.
If locking fails, implementations of this method may, but are not
required to, throw PermanentLockingException.
This method is not required
to determine whether locking actually succeeded and may return without
throwing an exception even when the lock can't be acquired. Lock
acquisition is only only guaranteed to be verified by the first call to
KeyColumnValueStore.mutate(StaticBuffer, List, List, StoreTransaction) on any given
txh.
The expectedValue must match the actual value present at the
key and column pair. If the true value does not match the
expectedValue, the lock attempt fails and
LockingException is thrown. This method may check
expectedValue. The mutate() mutate is required to check
it.
When this method is called multiple times on the same key,
column, and txh, calls after the first have no effect.
Locks acquired by this method must be automatically released on
transaction commit() or rollback().
Implementations which don't support locking should throw
UnsupportedOperationException.acquireLock in interface KeyColumnValueStoreacquireLock in class KCVSProxykey - the key on which to lockcolumn - the column on which to lockexpectedValue - the expected value for the specified key-column pair on which
to lock (null means the pair must have no value)txh - the transaction to usePermanentLockingException - the lock could not be acquired due to contention with other
transactions or a locking-specific storage problemBackendExceptionpublic void mutate(StaticBuffer key, List<Entry> additions, List<StaticBuffer> deletions, StoreTransaction txh) throws BackendException
KeyColumnValueStoretxh from previous calls to
KeyColumnValueStore.acquireLock(StaticBuffer, StaticBuffer, StaticBuffer, StoreTransaction)
, then writes supplied additions and/or deletions to
key in the underlying data store. Deletions are applied strictly
before additions. In other words, if both an addition and deletion are
supplied for the same column, then the column will first be deleted and
then the supplied Entry for the column will be added.
Implementations which don't support locking should skip the initial lock
verification step but otherwise behave as described above.mutate in interface KeyColumnValueStoremutate in class KCVSProxykey - the key under which the columns in additions and
deletions will be writtenadditions - the list of Entry instances representing column-value pairs to
create under key, or null to add no column-value pairsdeletions - the list of columns to delete from key, or null to
delete no columnstxh - the transaction to usePermanentLockingException - if locking is supported by the implementation and at least
one lock acquisition attempted by
KeyColumnValueStore.acquireLock(StaticBuffer, StaticBuffer, StaticBuffer, StoreTransaction)
has failedBackendExceptionCopyright © 2012–2015. All rights reserved.