How to make my appDomain live longer?

Here is the situation that we're in.

We are distributing our assemblies (purely DLL) to our clients (we don't have control over their environment).

They call us by passing a list of item's id and we search through our huge database and return items with highest price. Since we have our SLA (30 milisecond) to meet, we are caching our items in memory cache (using Microsoft MemoryCache) We are caching about a million items.

The problem here is, it only caches throughout our client application lifetime. When the process exit, so are all the cached items.

Is there a way i can make my memorycache live longer, so that subsequent process can reused cached items?

I have consider having a window service and allow all these different processes to communicate with one on the same box, but that's going to create a huge mess when it comes to deployment.

We are using AppFabric as our distributed cache but the only way we can achieve our SLA is to use memorycache.

Any help would be greatly appreciated. 开发者_如何转开发Thank you

---

I don't see a way to make sure that your AppDomain lives longer - since all the calling assembly has to do is unload the AppDomain...

One option could be -although messy too- to implement some sort of "persisting MemoryCache"... to achieve performance you could/would use a ConcurrentDictionary persisted in a MemoryMappedFile...

Another option would be to use a local database - could even be Sqlite and implement to cache interface in-memory such that all writes/updates/deletes are "write-through" while reads are pure RAM-access...

Another option could be to include a EXE (as embedded resource for example) and start that from inside the DLL if it is not running... the EXE provides the MemoryCache, communication could be via IPC (for example shared memory...). Since the EXE is a separate process it would stay alive even after unloading your AppDomain... the problem with this is more whether the client likes and/or permissions allow it...

I really like Windows Service approach although I agree that could be a deployment mess...

---

The basic issue seems to be that you don't have control of the run-time Host - which is what controls the lifespan (and hence the cache).

I'd investigate creating some sort of (light-weight ?) host - maybe a .exe or a service.

The bulk of your DLL's would hang off the new host, but you could still deploy a "facade" DLL which in turn called your main solution (tied to your host). Yes you could have the external clients call your new host directly but that would mean changing / re-configuring those external callers where-as leaving your original DLL / API in place would isolate the external callers from your internal changes.

This would (I assume) mean completely gutting and re-structuring your solution, particularly whatever DLLs the external callers currently hit, because instead of processing the requests itself it's just going to pass the request off to your new host.

Performance

Inter-process communication is more expensive than keeping it within a process - I'm not sure how the change in approach would affect your performance and ability to hit the SLA.

In-particular, sparking up a new instance of the host will incur a performance hit.