public class ExpectedValueCheckingStore extends KCVSProxy
KeyColumnValueStore wrapper intended for nontransactional stores
that forwards all but these two methods to an encapsulated store
instance:
acquireLock(StaticBuffer, StaticBuffer, StaticBuffer, StoreTransaction)mutate(StaticBuffer, List, List, StoreTransaction)ExpectedValueCheckingTransaction, track all expectedValue
arguments passed to acquireLock for each StoreTransaction.
When the transaction first mutate(...)s, the these classes cooperate
to check that all previously provided expected values match actual values,
throwing an exception and preventing mutation if a mismatch is detected.
This relies on a Locker instance supplied during construction for
locking.NO_ADDITIONS, NO_DELETIONS| Constructor and Description |
|---|
ExpectedValueCheckingStore(KeyColumnValueStore store,
Locker locker) |
| 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. |
protected StoreTransaction |
unwrapTx(StoreTransaction t) |
public ExpectedValueCheckingStore(KeyColumnValueStore store, Locker locker)
public void mutate(StaticBuffer key, List<Entry> additions, List<StaticBuffer> deletions, StoreTransaction txh) throws BackendException
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. 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.
This implementation supports locking when lockStore is non-null.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 failedBackendExceptionpublic void acquireLock(StaticBuffer key, StaticBuffer column, StaticBuffer expectedValue, StoreTransaction txh) throws BackendException
key 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.
This implementation supports locking when lockStore is non-null.
Consider the following scenario. This method is called twice with
identical key, column, and txh arguments, but with different
expectedValue arguments in each call. In testing, it seems titan's
graphdb requires that implementations discard the second expectedValue
and, when checking expectedValues vs actual values just prior to mutate,
only the initial expectedValue argument should be considered.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 problemBackendExceptionprotected StoreTransaction unwrapTx(StoreTransaction t)
Copyright © 2012–2015. All rights reserved.