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) Version: 3.2.0.4000 (3.2.0.4000)

Syntax

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

Parameters

key
Type: NHibernate.Cache..::..CacheKey

[Missing <param name="key"/> documentation for "M:NHibernate.Cache.ReadWriteCache.Get(NHibernate.Cache.CacheKey,System.Int64)"]

txTimestamp
Type: System..::..Int64

[Missing <param name="txTimestamp"/> documentation for "M:NHibernate.Cache.ReadWriteCache.Get(NHibernate.Cache.CacheKey,System.Int64)"]

Return Value

[Missing <returns> documentation for "M:NHibernate.Cache.ReadWriteCache.Get(NHibernate.Cache.CacheKey,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