public interface TxnObject
| Modifier and Type | Method and Description |
|---|---|
java.lang.String |
atomicToString()
Returns a String representation of the object using the provided transaction without looking
at a
TxnThreadLocal. |
void |
ensure()
Does an ensure.
|
void |
ensure(Txn self)
Does an ensure.
|
TxnLock |
getLock()
Gets the
TxnLock that belongs to this TxnObject. |
Stm |
getStm()
Returns the
Stm this TxnObject is part of. |
long |
getVersion()
Returns the current version of the transactional object.
|
java.lang.String |
toDebugString()
Returns a debug representation of the TxnObject.
|
java.lang.String |
toString()
Returns a String representation of the Object using the
Txn on the TxnThreadLocal. |
java.lang.String |
toString(Txn txn)
Returns a String representation of the object using the provided
Txn. |
Stm getStm()
Stm this TxnObject is part of. Once a TxnObject is created using some
Stm, it will never become part of another Stm.TxnLock getLock()
TxnLock that belongs to this TxnObject. This call doesn't cause any locking, it
only provides access to the object that is able to lock. The returned value will never be null.
This call also doesn't rely on a Txn.
java.lang.UnsupportedOperationException - if this operation is not supported.long getVersion()
This method doesn't look at the TxnThreadLocal.
void ensure()
IsolationLevel for more detail about the writeskew problem}
This can safely be called on an TxnObject that already is locked, although it doesn't provide much value since with a locked TxnObject, since the writeskew problem can't occur anymore because it can't be changed.
Unlike the TxnLock.acquire(LockMode) which is pessimistic, ensure is optimistic. This means that a conflict
can be detected once the transaction commits.
This method has no effect if the Txn is readonly, because a writeskew is not possible with a
readonly transaction.
This call lifts on the Txn stored in the TxnThreadLocal.
org.multiverse.api.exceptions.TxnExecutionExceptionorg.multiverse.api.exceptions.ControlFlowErrorensure(Txn)void ensure(Txn self)
IsolationLevel for more detail about the writeskew problem}
This can safely be called on an TxnObject that already is locked, although it doesn't provide much value since with a locked TxnObject, since the writeskew problem can't occur anymore because it can't be changed.
Unlike the TxnLock.acquire(LockMode) which is pessimistic, ensure is optimistic. This means that a conflict
can be detected once the transaction commits.
This method has no effect if the Txn is readonly, because a writeskew is not possible with a
readonly transaction.
self - the Txn this call lifts on.java.lang.NullPointerException - if self is null.org.multiverse.api.exceptions.TxnExecutionExceptionorg.multiverse.api.exceptions.ControlFlowErrorensure()java.lang.String toDebugString()
java.lang.String toString()
Txn on the TxnThreadLocal.toString in class java.lang.Objectorg.multiverse.api.exceptions.TxnExecutionExceptionorg.multiverse.api.exceptions.ControlFlowErrorjava.lang.String toString(Txn txn)
Txn.txn - the Txn used.java.lang.NullPointerException - if tx is null.org.multiverse.api.exceptions.ControlFlowErrorjava.lang.String atomicToString()
TxnThreadLocal. The outputted value doesn't need to be consistent from some point
in time, only a best effort is made.