Freigeben von Daten zwischen AppDomains

Question

Ich habe einen Prozess, der mehrere AppDomains haben kann. Jede AppDomain sammelt einige Statistiken. Nach einer bestimmten Zeit möchte ich diese Statistik sammeln und sie in einer Datei speichern.

Eine Möglichkeit, dies zu tun, ist Remoting, die ich vermeiden möchte.

Die einzige andere Technik, die ich im Sinn habe, ist das Speichern der Daten jeder AppDomain in einer Datei, und nach einer bestimmten Zeit sammelt eine der AppDomain alle Daten und akkumuliert sie.

Aber es wäre ideal, wenn dies alles im Speicher ausgeführt werden könnte, ohne die Kosten für die Serialisierung der Informationen zwischen AppDomains zu übertragen. Hat jemand Ideen?

Answer 1

Die einzige Möglichkeit, die Serialisierung zu vermeiden, besteht darin, Ihre Daten mit Objekten darzustellen, die von MarshalByRefObject abgeleitet sind. In diesem Fall müssen Sie jedoch die Kosten für das Marshalling über die AppDomain-Grenzen hinweg tragen. Dies kann auch das Refactoring/Neuschreiben eines Großteils Ihres Codes beinhalten.

Wenn man davon ausgeht, dass das Marshalling per Referenz keine Option ist, müssen Sie irgendwann serialisieren. Es kann einfach nicht vermieden werden. Ein Weg, dies zu tun, ist, wie Neil Barnwell vorschlägt, mit einer Datenbank, eine andere würde mit einer lokalen Datei sein, wie Sie sich selbst vorschlagen.

Eine andere Möglichkeit, die möglicherweise abhängig von Ihrer Lieferungszeitlinie und/oder .NET 4.0-Übernahme machbar ist, wäre die Verwendung einer Speicherabbilddatei, siehe .Net Framework 4.0: Using memory mapped files.

Answer 2

Ich weiß es zu schätzen, dass Sie dies im Speicher behalten möchten, aber mein erster Vorschlag wäre, die Daten in eine Datenbank zu schreiben und von dort abzufragen. Remoting ist immer noch ein Remote-Aufruf, bei dem ein Großteil der "Kosten" für die Verwendung eines Datenbankservers anfällt, und Sie müssen eine Transaktionsverarbeitung einbauen, um sicherzustellen, dass Sie keine Daten verlieren. Wenn Sie in eine SQL Server-Datenbank schreiben, steht Ihnen Transaktionsunterstützung zur Verfügung, die auf Sie wartet. Für Abfragen ist sie schnell, schnell und schnell.

Answer 3

Ich neige dazu zu sagen, nur Remoting zu verwenden. Das Schreiben der Daten in eine Datei erfordert ebenfalls eine Serialisierung. Serialisierung scheint fast unvermeidlich zu sein, egal welche Technologie Sie verwenden. Sie müssen Daten von einer Anwendungsdomäne zu einer anderen übertragen, indem Sie einen Kanal verwenden, und Sie müssen die Daten serialisieren, um sie durch den Kanal zu bekommen.

Die einzige Möglichkeit, Serialisierung zu vermeiden, scheint Shared Memory zu verwenden, damit beide Anwendungsdomänen auf die Daten zugreifen können, ohne jemals einen Kanal zu durchlaufen. Selbst das tiefe Klonen der Daten aus dem Speicher einer Anwendungsdomäne in den Speicher des anderen ist im Kern nichts anderes als eine binäre Serialisierung (wobei das Ergebnis nicht notwendigerweise in aufeinanderfolgenden Speicherstellen gespeichert wird).

Answer 4

Es ist möglich, Daten zwischen AppDomains ohne die Kosten des Marshalling zu teilen. Aber es ist ein ziemlich hacky Weg. Sie können ein Quelldatenobjekt erstellen, das als Referenz zwischen allen Anwendungsdomänen verwendet wird. Auf diese Weise erhalten Sie alle Daten in einem gemeinsamen Objekt ohne die Kosten des Marshalling. Klingt zu einfach um wahr zu sein?

Die erste Sache ist zu wissen, wie Daten zwischen AppDomains ohne Marshalling teilen. Dazu erhalten Sie die Objektadresse Ihres Datenquellenobjekts über Marshal.UnsafeAddrOfPinnedArrayElement. Dann übergeben Sie diesen IntPtr an alle AppDomains, die daran interessiert sind. In der Ziel-Anwendungsdomäne müssen Sie dieses IntPtr zurück in eine Objektreferenz umwandeln, was mit JIT :: CastAny erledigt werden kann, wenn Sie ein Objekt von einer Methode zurückgeben und dessen Zeiger auf den Stapel schieben.

Viola Sie haben ein Objekt als einfacher Zeiger zwischen AppDomains geteilt und Sie erhalten InvalidCastExceptions. Das Problem ist, dass Sie für alle Ihre AppDomains LoaderOptimization festlegen müssen.MultiDomain, um sicherzustellen, dass die Assembly, die den freigegebenen Datentyp definiert, als neutraler AppDomain-Typ geladen wird, der denselben Methodentabelle-Zeiger zwischen allen AppDomains aufweist.

Sie können eine Beispielanwendung finden, die genau dies als Teil von WMemoryProfiler tut. Siehe diesen Link für eine mehr detailed explanation and download link zum Beispielcode.

Der Grundcode ist

[LoaderOptimization(LoaderOptimization.MultiDomain)] 
static public void Main(string[] args) 
{ 

    // To load our assembly appdomain neutral we need to use MultiDomain on our hosting and child domain 
    // If not we would get different Method tables for the same types which would result in InvalidCastExceptions 
    // for the same type. 
    var other = AppDomain.CreateDomain("Test"+i.ToString(), AppDomain.CurrentDomain.Evidence, new AppDomainSetup 
     { 
      LoaderOptimization = LoaderOptimization.MultiDomain, 
     }); 

    // Create gate object in other appdomain 
    DomainGate gate = (DomainGate)other.CreateInstanceAndUnwrap(Assembly.GetExecutingAssembly().FullName, typeof(DomainGate).FullName); 

    // now lets create some data 
    CrossDomainData data = new CrossDomainData(); 
    data.Input = Enumerable.Range(0, 10).ToList(); 

    // process it in other AppDomain 
    DomainGate.Send(gate, data); 

    // Display result calculated in other AppDomain 
    Console.WriteLine("Calculation in other AppDomain got: {0}", data.Aggregate); 
    } 
}