com.sleepycat.je.rep.utilint

Class SimpleTxnMap<T extends Txn>

java.lang.Object

com.sleepycat.je.rep.utilint.SimpleTxnMap<T>

Type Parameters:

T - the type of Txn object stored as values in the map

public class SimpleTxnMap<T extends Txn>
extends Object

SimpleTxnMap provides a customized (but limited functionality) map that's well suited to the tracking of open transactions. Transactions are entered into this map when they are first created, referenced while they are alive via their transaction id and subsequently, removed upon commit or abort. So the map access pattern for each transaction looks like the sequence: put [get]* remove For JE applications, like KVS, transactions can pass through this map at the rate of 30K to 60K transactions/sec, so the map needs to process these operations efficiently. This map tries to be efficient for the put, get, remove operations by: 1) Avoiding any memory allocation for the typical: put, get, remove sequence. In contrast, a heap entry uses 24 bytes for each entry plus 16 bytes for the long object argument when using compressed oops. It could be that the heap storage could be replaced by stack storage for the long object argument since it's a downward lexical funarg, but I don't know if the jvm does such analysis. 2) Having a very short instruction code path for the typical case. The data structure used here is very simple, and consists of two maps. 1) An array based map indexed by the low bits of the transaction id. 2) A regular java Map The array based map is the preferred location for map entries. If the slot associated with the transaction id is occupied, we fall back to the the java Map. So the best case behavior is as if the map were implemented entirely as an array and the worst case is that we will do an extra integer mask, array index and compare operation before we resort to using the java Map. Given the behavior of transactions, we expect that the vast majority of the operations will be implemented by the array map. This class provides a minimal subset of the operations provided by Map. All methods are synchronized. This works well for replica replay in conjunction with a jvm's thread biased locking strategy, but we may need explicit locks for other usage.

Constructor Summary

Constructors

Constructor and Description
SimpleTxnMap(int arrayMapSize)

Method Summary

Modifier and Type	Method and Description
void	clear() The methods below are not used in critical paths and are not optimized.
T	get(long txnId)
HashMap<Long,T>	getBackupMap() For test use only
Map<Long,T>	getMap() Returns a new map containing the current snapshot of transactions in this map.
boolean	isEmpty()
void	put(T txn) Adds a txn to the map.
T	remove(long txnId) Removes the txn with that key, if it exists.
int	size()

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

SimpleTxnMap

public SimpleTxnMap(int arrayMapSize)

Method Detail

put

public void put(T txn)

Adds a txn to the map. Note that the "put" operation in keeping with transaction behavior does not expect to be called while a txn with that ID is already in the map.

get

public T get(long txnId)

remove

public T remove(long txnId)

Removes the txn with that key, if it exists.

Returns:

the Txn that was removed, or empty if it did not exist.

size

public int size()

isEmpty

public boolean isEmpty()

clear

public void clear()

The methods below are not used in critical paths and are not optimized. They they are O(n) complexity. We can revisit with change in usage.

getMap

public Map<Long,T> getMap()

Returns a new map containing the current snapshot of transactions in this map.

getBackupMap

public HashMap<Long,T> getBackupMap()

For test use only