I suggest you ...

65 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Dmitri MaximovAdminDmitri Maximov (Project manager, Xtensive LLC) shared this idea  ·   ·  Admin →

    6 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Malisa NcubeMalisa Ncube commented  · 

        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 NcubeMalisa Ncube commented  · 

        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.

      • AraAra commented  · 

        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.

      Feedback and Knowledge Base