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?
the Telerik team