Beim Überprüfen der Ereignisprotokolle auf meinem Tridion Content Management Server (ich verwende die Version 2009) sehe ich Warnungen, die sagen:
%Vor%Welche Programmier- / Templating-Praktiken werden dies wahrscheinlich verursachen?
EDIT: Bis jetzt hatten wir einige gute Vorschläge:
Tatsächlich handelt es sich bei beiden um solides Gold, und Sie sollten Ihren eigenen Code für diese Anti-Muster überprüfen. (Die Engine hat einen Verweis auf eine Sitzung, das macht Sinn.) Ich habe jedoch die Codebasis durchsucht, die das Problem verursacht, und ich habe keine davon gefunden. Also - hat jemand noch mehr Ideen? Ich würde auch Vorschläge begrüßen, wie man solche Dinge debuggen oder den problematischen Code eingrenzen kann.
Das Problem tritt nicht nur beim Speichern einer Sitzung auf, sondern auch beim Speichern eines beliebigen TOM.NET-Objekts ( Component , Page usw.). Jedes dieser Objekte hat einen internen Verweis auf die Sitzung, die von jedem Zugriff auf das Objekt erstellt wurde, muss möglicherweise zur Sitzung zurückkehren, um die angeforderten Informationen von Tridion abzurufen.
Obwohl die meisten Eigenschaften, die für den Elementtyp "nativ" sind, scheinbar abgerufen und in einer Instanz beibehalten werden, kann ein Aufruf wie LoadApplicationData (zurück) auf die Sitzung zugreifen (müssen), um auf die angeforderten Daten zuzugreifen. Und wenn dieser Aufruf dann in einem anderen Thread passiert, erhalten Sie die Warnmeldung, die Sie erwähnen.
Ich habe begonnen, mir jedes TOM.NET-Objekt anzusehen, das ich mit Argwohn behalte, und lade viele Daten vor, die ich später vielleicht brauche, wenn ich das Objekt zum ersten Mal aus seiner Sitzung lade.
Ich möchte auch einen Kommentar basierend auf früheren Erfahrungen hinzufügen. Die folgenden Szenarien:
Kann mehrere Probleme verursachen, abgesehen von Speicherverlusten während der Veröffentlichung.
Publisher beginnt, Speicher zu verbrauchen, bis er nicht mehr reagiert (Sie können weder stoppen noch neu starten oder deaktivieren) und Sie müssen den Server neu starten.
Diese Probleme können bei massiven Veröffentlichungen immer schlimmer werden
So wird empfohlen, dass alles, was Sitzung, Engine, Paket verwendet, in nicht statische
konvertiert werden sollAls Beispiel wird aus dem folgenden Code, der zum Initialisieren von allen Vorlagen verwendeten Utilities verwendet wird,
gewechselt %Vor%in
%Vor%Kann viele Probleme speichern
Ich habe festgestellt, dass dieser Fehler auftritt, wenn Sie das Sitzungsobjekt in einer statischen Variablen in einer Vorlage speichern. Es funktioniert einwandfrei im Debug-Modus, aber sobald ich einen Multithread-Publisher (d. H. Mehr als einen Rendering-Thread) starte, wird dieses Problem von einem hässlichen Kopf ausgelöst.
Ein anderes Szenario besteht darin, dass Ihr Ereignissystem, Ihre Vorlage oder Ihr Workflow-Code untergeordnete Threads startet und die Sitzungs- oder Engine-Objekte in diese ohne entsprechende Sperren übergibt.
Im Wesentlichen alles, was außerhalb des Modells der Single-Threaded Apartments liegt, auf dem die Objekte Engine und Session basieren: Ссылка
Tags und Links tridion