Do not return an item whose timestamp is later than the current transaction timestamp. (Otherwise we might compromise repeatable read unnecessarily.) Do not return an item which is soft-locked. Always go straight to the database instead.

Namespace:  NHibernate.Cache
Assembly:  NHibernate (in NHibernate.dll)

Syntax

Visual Basic (Declaration)
Public Function Get ( _
	key As CacheKey, _
	txTimestamp As Long _
) As Object
C#
public Object Get(
	CacheKey key,
	long txTimestamp
)
Visual C++
public:
virtual Object^ Get(
	CacheKey^ key, 
	long long txTimestamp
) sealed
JavaScript
function get(key, txTimestamp);

Parameters

key
Type: NHibernate.Cache..::.CacheKey
txTimestamp
Type: System..::.Int64

Implements

ICacheConcurrencyStrategy..::.Get(CacheKey, Int64)

Remarks

Note that since reading an item from that cache does not actually go to the database, it is possible to see a kind of phantom read due to the underlying row being updated after we have read it from the cache. This would not be possible in a lock-based implementation of repeatable read isolation. It is also possible to overwrite changes made and committed by another transaction after the current transaction read the item from the cache. This problem would be caught by the update-time version-checking, if the data is versioned or timestamped.

See Also