Friday, February 11, 2011
Wednesday, February 2, 2011
Tuesday, February 1, 2011
NHibernate Cache Providers
When considering which of the cache providers availible in NHibernate, we are presented with a list which includes:
Velocity: Hard to find detailed info on this provider.
Prevalence: An Object based caching provider which isolates the caching to objects rather than data and queries. See Prevayler.
Memcache: Handles server farms and exploit the additional memory throughout the farms’ multiple servers for use in caching.
SharedCache: Designed to provide redundancy of the cache across a multi-server farm.
SysCache: Standard ASP.NET caching provider which does not exploit the additional memory throughout a server farm.
SysCache2: Similar to SysCache, but also allows for the use of SQL Dependency to triggers cache expiration.
The scope of my problem is a single web server, which eliminates Memcache and SharedCache.
My first choice would be SysCache, as long as we have no external influences on our underlying database which would have a direct impact on the integrity of our cached data. So, if the application has exclusive control over when the data is modified, SysCache sounds like it would be the solution, as there would be no need to listen for changes outside the scope of our application. The cache provider is supposed to keep track of these types of things.
If there are outside influences to our data, and we need to listen for potential changes that happen OUTSIDE of our application, SysCache2 would be the solution. You just have to identify all of the tables that may change and configure the dependencies accordingly.
Prevayler
1. All modifications to your business objects must be encapsulated in transaction objects.
2. All your transactions must be completely deterministic. For example, don ' t call System.currentTimeMillis () from within a transaction (or within any business object code called indirectly by a transaction), because it will give a different answer every time the transaction is run. (If you do want to know the time, Prevayler provides an ' official ' timestamp, assigned when the transaction is first written to the journal. See the Transaction interface.)
Note that any hardware input or output is inherently nondeterministic, and therefore violates this rule. Do all I / O outside of Prevayler transactions.
3. All your transactions and business objects must be serializable, so that they can be written to the journal and snapshot. (You can also configure your own serialization mechanisms if you don ' t want to use Java serialization.)
4. Transactions can ' t carry direct object references (pointers) to business objects. This has become known as the baptism problem because it ' s a common beginner pitfall. Direct object references don ' t work because once a transaction has been serialized to the journal and then deserialized for execution its object references no longer refer to the intended objects - - any objects they may have referred to at first will have been copied by the serialization process! Therefore, a transaction must carry some kind of string or numeric identifiers for any objects it wants to refer to, and it must look up the objects when it is executed."