| java.lang.Object com.tc.object.tx.ClientTransactionManagerImpl
Inner Class :public static class ThreadTransactionLoggingStack | |
Method Summary | |
public void | addDmiDescriptor(DmiDescriptor dd) | public void | addReference(TCObject tco) | public void | apply(TxnType txType, List lockIDs, Collection objectChanges, Set lookupObjectIDs, Map newRoots) | public void | arrayChanged(TCObject source, int startPos, Object array, int length) | public boolean | begin(String lockName, int lockLevel) | public void | checkWriteAccess(Object context) | public void | commit(String lockName) In order to support ReentrantLock, the TransactionContext that is going to be removed when doing a commit may not
always be at the top of a stack because an reentrant lock could issue a lock within a synchronized block (although
it is highly not recommended). | public void | createObject(TCObject source) | public void | createRoot(String name, ObjectID rootID) | public void | disableTransactionLogging() | public void | enableTransactionLogging() | public void | fieldChanged(TCObject source, String classname, String fieldname, Object newValue, int index) | public ChannelIDProvider | getChannelIDProvider() | public ClientTransaction | getTransaction() | public boolean | isHeldByCurrentThread(String lockName, int lockLevel) | public boolean | isLockOnTopStack(String lockName) | public boolean | isLocked(String lockName, int lockLevel) | public boolean | isTransactionLoggingDisabled() | public void | literalValueChanged(TCObject source, Object newValue, Object oldValue) | public int | localHeldCount(String lockName, int lockLevel) | public void | lock(String lockName, int lockLevel) | public void | logicalInvoke(TCObject source, int method, String methodName, Object[] parameters) | public void | notify(String lockName, boolean all, Object object) | public int | queueLength(String lockName) | public void | receivedAcknowledgement(SessionID sessionID, TransactionID transactionID) | public void | receivedBatchAcknowledgement(TxnBatchID batchID) | public boolean | tryBegin(String lockName, WaitInvocation timeout, int lockLevel) | public void | unlock(String lockName) | public void | wait(String lockName, WaitInvocation call, Object object) | public int | waitLength(String lockName) |
begin | public boolean begin(String lockName, int lockLevel)(Code) | | |
checkWriteAccess | public void checkWriteAccess(Object context)(Code) | | |
commit | public void commit(String lockName) throws UnlockedSharedObjectException(Code) | | In order to support ReentrantLock, the TransactionContext that is going to be removed when doing a commit may not
always be at the top of a stack because an reentrant lock could issue a lock within a synchronized block (although
it is highly not recommended). Therefore, when a commit is issued, we need to search back the stack from the top of
the stack to find the appropriate TransactionContext to be removed. Most likely, the TransactionContext to be
removed will be on the top of the stack. Therefore, the performance should be make must difference. Only in some
weird situations where reentrantLock is mixed with synchronized block will the TransactionContext to be removed be
found otherwise.
|
disableTransactionLogging | public void disableTransactionLogging()(Code) | | |
enableTransactionLogging | public void enableTransactionLogging()(Code) | | |
isHeldByCurrentThread | public boolean isHeldByCurrentThread(String lockName, int lockLevel)(Code) | | |
isLockOnTopStack | public boolean isLockOnTopStack(String lockName)(Code) | | |
isLocked | public boolean isLocked(String lockName, int lockLevel)(Code) | | |
isTransactionLoggingDisabled | public boolean isTransactionLoggingDisabled()(Code) | | |
localHeldCount | public int localHeldCount(String lockName, int lockLevel)(Code) | | |
receivedBatchAcknowledgement | public void receivedBatchAcknowledgement(TxnBatchID batchID)(Code) | | |
|
|