Distributed 2nd level Cache (and not Replicated 2nd level Cache)

7 posts, 0 answers
  1. Alexandre
    Alexandre avatar
    1 posts
    Member since:
    Apr 2009

    Posted 27 Apr 2009 Link to this post

    Hi,

    I have heavily used several ORM that are available on the market. OpenAccess seems great : it has lots of great features and seems to stay simple and usable.

    OpenAccess says it has distributed 2nd level cache, but it is a replicated 2nd level cache : objects data are replicated in each program memory space. They are not dispatched on each program memory space.

    - We want mimimum roundtrips to the database : So we need a second level cache
    - We have lots of data : So we need a distributed cache

    We are convinced to get OpenAccess, but we really need this feature. So my question is:

    Which interface/subclasses/methods can we implement to add this kind of fonctionality to OpenAccess ? Do you have a ICacheProvider to be plugged into OpenAccess to manage 2nd level cache ?

    Regards

  2. Thomas
    Admin
    Thomas avatar
    590 posts

    Posted 29 Apr 2009 Link to this post

    Bon jour Alexandre,

    I think I should explain a bit what our second level cache does:

    The 2nd level cache is a container for object and query data; both kind of entries are configurable separately (enabling, maximum number of entries). The cache is filled only be read access, which means the content will be what the application has demanded from the database. When the application updates/deletes persistent objects, the entries that depend on them are evicted from the cache. This means, that if you change the name of a persistent Person instance, the corresponding entry is removed from the data cache, but also all query cache entries depending on the class Person are removed.
    All this happens in the process memory space, as the 2nd level cache is an in-process cache.

    When there is a need to have multiple processes/applications using the 2nd level cache, we need a way to evict changed/deleted entries in all processes/applications. Currently, we provide an implementation using MSMQ as the transport vehicle for our eviction messages. Why MSMQ? Because we can then use reliable multicasts to send such eviction messages to many participants. Again, we are only evicting entries from the various participants in such a setup (we call it cache cluster). We never push new/updated data to the 2nd level caches and local reading is still the only way to populate the local cache instance.

    So I don't think we have a replicated cache (as we only send eviction messages around, never object data), but it is a distributed cache in the sense, that each peer in the cache cluster might have only 'its' objects cached and that the cache cluster is kept synchronous.

    At the moment, we don't provide an API for you to hook your own eviction distribution mechanism or your own cache implementation into OpenAccess. Which functionality is missing in your context?

    Best wishes,
    Thomas
    the Telerik team

    Instantly find answers to your questions on the new Telerik Support Portal.
    Check out the tips for optimizing your support resource searches.
  3. DevCraft banner
  4. Allen
    Allen avatar
    42 posts
    Member since:
    Nov 2014

    Posted 10 Nov 2014 in reply to Thomas Link to this post

    In China, there is huge numbers of developer looking good to the capability of Telerik Data Access. Is it possible to expose Cache module out, like extend some API to facilitate distributed clustering cache? 
    Such as, MongoDB, Memcached, Redis, Cassandra....
  5. Thomas
    Admin
    Thomas avatar
    590 posts

    Posted 12 Nov 2014 Link to this post

    Hello Zhen Peng Cai,

    it is currently not possible to place the cache outside of the process. The whole idea of the L2 cache is that there is very fast access to it which excludes serialization and networking.  The only thing that we can do is to provide an API that can be used to notify other processes when evictions need to occur. We have not decided yet whether or not to make this API part of the product. Please describe to us your scenario and the need to have a mechanism besides the MSMQ implementation that comes out of the box.

    Regards,
    Thomas
    Telerik
     
    OpenAccess ORM is now Telerik Data Access. For more information on the new names, please, check out the Telerik Product Map.
     
  6. Allen
    Allen avatar
    42 posts
    Member since:
    Nov 2014

    Posted 20 Nov 2014 in reply to Thomas Link to this post

    Hello, Thomas.
    Very happy can you spare some time to reply to me.
    Maybe my expression error, let you misunderstood.
    Perhaps, I already know what I want to do.
    Keywords: distributed NoSQL database.
    Thank you very much.
  7. Thomas
    Admin
    Thomas avatar
    590 posts

    Posted 21 Nov 2014 Link to this post

    Hello Zhen Peng Cai,

    do I understand you right: You want to reuse the second level cache synchronization code for your own purposes? Technically this would be possible, but there is no documentation for that. All I can do is to describe what we are doing in the second level cache:

    The second level cache is essentially a size limited, LRU restricted Dictionary<OID,State> . This means, the cache contains a copy of the data that was locally read from the database. This cache is in process, no need for serialization and network code. When the DataAccess runtime stores an update to a persistent object, the cache is notified for an eviction (removal) of the respective OID. Next time the state for the OID is required, it will not be found in the cache and therefore rows from the database are fetched. In this fetching process, a copy is placed in the cache again. 
    When there are two caches in parallel for the same data, the caches must be synchronized. Synchronization just removes entries by sending eviction messages to all partners in this cache cluster. These eviction messages contain only the OIDs for the objects that changed, no additional data.
    This synchronization is currently implemented using MSMQ as the transport mechanism, because this allows us to leverage the PGM (pragmatic general multicast) protocol.

    Hope this clarifies a bit our second level cache implementation. If you need more information, please let us know what you really intend to achieve and what the constraints are.

    Regards,
    Thomas
    Telerik
     
    OpenAccess ORM is now Telerik Data Access. For more information on the new names, please, check out the Telerik Product Map.
     
  8. Allen
    Allen avatar
    42 posts
    Member since:
    Nov 2014

    Posted 28 Nov 2014 in reply to Thomas Link to this post

    I see, thank you,thomas
Back to Top
DevCraft banner