6 comments

Add a comment…

Sign in

prestine

Your email address

Check!

invalid email

(thinking…)

Reset

or sign in with

• 
• 

UserVoice password

Forgot password?

Create a password

Your name

I agree to the terms of service

You'll receive a confirmation email with a link to create a password (optional).

Signed in as (Sign out)

Close

Close

Post comment Submitting...

• AdminDmitri Maximov (Project manager, Xtensive LLC) commented  ·  January 30, 2012 22:53  ·  Delete

  L2 Cache feature is preliminary planned for 4.7 version (Summer 2012)

• Malisa Ncube commented  ·  June 12, 2011 05:07  ·  Delete

  Some interesting read from

  http://weblogs.asp.net/pglavich/archive/2011/05/31/cacheadapter-now-a-nuget-package.aspx

• Malisa Ncube commented  ·  June 02, 2011 11:10  ·  Delete

  Something else that came to mind...

  It is important to force expiration of items in the cache, or to instruct loading of fresh data.

  This may be nicely done using a Linq extension method. e.g.

  //Query
  var query = from p in session.Query.All<Country>().ForceReload()

  Subsequent country queries will use the data from the cache until it either expires, rejected or forced out by query.

• Malisa Ncube commented  ·  June 02, 2011 08:07  ·  Delete

  I think this is a very valuable feature. We don't want query to hit DB server again for certain reference data. I would prefer if we have rather a caching adapter with relevant attributes.

  [HierachyRoot]
  [Cache(TimeOut = 500)]
  public class Country : Entity
  {
  //implementation
  }

  It will be nice of settings such as timeout can be placed in the app.config file and can be adjusted after learning about hits and misses.

  [Cache()]
  //this should search the config file or use defaults.

  The implemntation of this cach can use a provider model and the user should then be able to use AppFabric, System.Runtime.Caching or some other caching framework.

  Some metadata should be permitted to enable quering the cache. e.g. all hits that have acertain tag/metadata.

  The api should expose events that can be monitored to subscribe for hits or misses. The % hits would help shape the ORM for high performance.

• Ara commented  ·  May 03, 2011 02:30  ·  Delete

  My previous post applies if you're considering moving beyond simply version checks at the outermost transaction level... if you're considering caching recently used entities and invalidating/updating them in-memory when they're modified from a distributed node (e.g. in the case of multiple web servers).

  There are many use cases for business applications where end users only interact with recent data/entities, and historical data is only occasionally referenced. Order processing is one such example, where the system is not interested in the thousands/millions of historical orders, but rather the recent handful that need to be processed and fulfilled.

  Performance and scalability can be greatly improved through distributed caches for these types of use cases, even if they only form a subset of a larger application.

• Ara commented  ·  May 02, 2011 22:00  ·  Delete

  I hope the implementation is pluggable so that one can be made to work with the Windows Azure App Fabric Caching Service (http://blogs.msdn.com/b/sqlazure/archive/2011/05/02/10160065.aspx) for distributed caching across multiple web servers (e.g. ASP.NET MVC project)